☰

在被毁坏的系统上获取 root shell

tag-icon • tag-icon linux shell root
在被毁坏的系统上获取 root shell

由于在输入 ctrl-c 时checkinstall我处于这个问题描述的状态：在根目录下解压 tar 会破坏整个系统

但是我没有打开 root shell。第一个答案中列出的命令在其他方面效果很好，例如

/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 --library-path /usr/lib/x86_64-linux-gnu /usr/bin/ls

此时有什么技巧可以获取 root 用户吗？ sudo 和 su 都有错误。

为了su： su: Module is unknown

为了sudo： sudo: effective uid is not 0, is /usr/bin/sudo on a filesystem with the 'nosuid' option set or an NFS file system without root privileges

答案1

我的第一个想法是“这肯定不可能发生。”但果然……你并非第一次遇到此行为checkinstall：

我使用 checkinstall 从源代码构建 libtorrent 后对其进行打包，但在执行过程中按下 Ctrl-C 导致系统崩溃。

...

从那时起，所有命令都被破坏，包括 bash、ls 和 sudo。

不确定为什么，但我相信这是由于 checkinstall 想要恢复不存在或错误的备份 tar 档案造成的。

我必须在恢复介质上重新启动才能将符号链接从 /usr/lib 恢复到 /lib

你的关联提到有问题的档案在通过 root ( /) 提取时导致系统崩溃：

root@system:~# tar --no-same-owner --no-same-permissions --no-overwrite-dir -C / -xzvf test.tar.gz 
./
./lib/
./lib/test
...

GitHub 上受影响的用户还发现了一个checkinstall做类似事情的地方（摘录至/）：

也许是因为这里的第二个 Ctrl-C 中断了第一个 tar 命令：

   echogn "Restoring overwritten files from backup..."
   cd ${TMP_DIR}/BACKUP
      files=$(ls -A)
      $TAR -cpf - $files | $TAR -f - -xvpC / &> /dev/null
   okfail

因此，修复/lib符号链接是可行的。

但是由于您没有正常运行sudo的或su，我怀疑您需要从恢复环境（例如实时 CD）启动系统才能修补损坏的符号链接（通过移动空的/liba lamv /lib /lib_moved然后重新建立符号链接 a la ln -s usr/lib /lib）。

获得 root 访问权限的唯一其他方法是利用漏洞（无论如何，漏洞可能不会在这种状态下的系统中运行）。

相关内容