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

Question

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

除了我的非 root 用户帐户可能被泄露（密码泄露、ssh 密钥泄露等）之外，是否还有其他进入分离的、受密码保护的屏幕会话的向量我应该担心，或者是否可以分离屏幕会话被认为是惰性的？

Answer 1

如果您在 screen 会话中有一个 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?l到 shell 的输入流中。\ek是让应用程序（或任何可以写入终端设备的任何东西）设置窗口标题的控制序列（请参阅屏幕手册中的“命名窗口”部分），\e[21t并使终端在应用程序的标准输入上报告其标题（ screen 没有记录这个序列，但确实实现了它；你可以CSI Ps ; Ps ; Ps ; t在xterm 控制序列列表下找到它。事实上，至少在 screen 4.0.3 下，所有控制字符都从报告的标题中剥离，所以 shell 读取lfoobar（假设?]未绑定到编辑命令）并且没有换行符。因此攻击者实际上无法以这种方式执行命令，但可以填充类似的命令chmod u+s /bin/sh 后面跟着很多空格和一个看起来很可能的提示。

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

Answer 2

我认为这是一个安全问题，因为“除了我的非 root 用户帐户被入侵的可能性”可能相当大。

但除此之外还有其他增加的风险。例如，您现在已经打开了自己的理论漏洞，该漏洞允许更改屏幕套接字目录中的权限（/var/run/screen在我的系统上，但有时/tmp会使用）。该漏洞现在有一条获取 root 的路径，否则可能不会。

sudo还有其他优点，如果您可以训练自己在每个命令中使用它而不是执行sudo su -. 它记录操作（除非您远程登录，否则不会有意义地提高安全性，但会为您提供已完成操作的跟踪）。它通过要求对每个命令有意升级，而不是切换到完全特权的会话来帮助防止事故。