让 root shell 在分离的屏幕会话中运行是否安全?

让 root shell 在分离的屏幕会话中运行是否安全?

我很好奇让 root shell 在分离的屏幕会话中运行的安全性。我通常从不这样做。

除了我的非 root 用户帐户被泄露的可能性(密码暴露、ssh 密钥被泄露等)之外,是否还有其他进入分离的、受密码保护的屏幕会话的媒介,我应该担心,或者分离的屏幕可以会话被认为是惰性的吗?

答案1

如果您在屏幕会话中拥有 root shell(无论是否分离、是否受密码保护),并且您的screen可执行文件不是 setxid,那么获得您权限的攻击者就可以在该 shell 中运行命令。如果没有别的办法,他们可以这样做追踪画面过程。

如果 screen 是 setuid 或 setgid,并且会话已分离并受密码保护,则原则上它需要 screen 密码才能在该 shell 中运行命令。如果这个原则成立,那么仅危害您帐户的人就必须安装木马并等待您输入密码。然而,攻击面(即由于错误或配置错误而可能出现问题的地方的数量)非常大。除了基本的系统安全功能之外,您还信任:

  • 屏幕以确保密码检查正确。
  • screen 以阻止通过其他方式访问会话。
  • 屏幕以正确使用操作系统访问控制机制(例如管道上的权限)。
  • 内核正确执行 ptrace 安全检查(这是漏洞的常见来源)。
  • 正在运行的 shell 不会做任何愚蠢的事情。
  • 其他一些功能不会咬你。

“其他一些不会咬你的功能”:是的,这很模糊。但这始终是安全问题。您可能会认为这只是一厢情愿,但您真的考虑到了一切吗?例如…

只要您可以写入终端设备,就可以将数据注入到该 shell 的输入中。在我的机器上屏幕的默认配置下:

printf '\ekfoo\017bar\e\\' >/dev/pts/33
printf '\e[21t' >/dev/pts/33

这会插入␛]lfoobar␛lshell 的输入流中。\ek是让应用程序(或任何可以写入终端设备的东西)设置窗口标题的控制序列(请参阅屏幕手册中的“命名窗口”部分),\e[21t并使终端在应用程序的标准输入上报告其标题(屏幕没有记录此序列,但确实实现了它;您可以CSI Ps ; Ps ; Ps ; txterm 控制序列列表。事实上,至少在屏幕 4.0.3 下,所有控制字符都从报告的标题中删除,因此 shell 读取lfoobar(假设␛]未绑定到编辑命令)并且没有换行符。因此,攻击者实际上无法以这种方式执行命令,但可以填充命令,例如chmod u+s /bin/sh后跟大量空格和看起来可能的提示符。

Screen 实现了其他几个类似的风险控制序列,我不知道它们的漏洞潜力有多大。但希望现在您可以看到屏幕会话密码提供的保护并不是那么好。诸如 sudo 之类的专用安全工具出现漏洞的可能性要小得多。

答案2

我认为这是一个安全问题,因为“除了我的非根用户帐户被泄露的可能性”可能相当大。

但除此之外,还有其他增加的风险。例如,您现在已经向自己开放了一种理论漏洞,该漏洞允许您更改屏幕套接字目录中的权限(/var/run/screen在我的系统上,但有时/tmp会使用)。该漏洞现在有一条获得 root 权限的途径,否则可能无法获得 root 权限。

sudo如果您可以训练自己在每个命令中使用它而不是执行sudo su -.它记录操作(除非您远程记录,否则不会显着提高安全性,但确实可以让您了解发生了什么你已经完毕)。它通过要求对每个命令有意升级而不是切换到完全特权的会话来帮助防止事故。

答案3

screen 创建的管道只能由所有者访问,因此这不应该是安全问题。

相关内容