OpenSSH <=6.8 X11安全bug

OpenSSH <=6.8中存在一个安全问题，允许通过ssh-X连接客户端的恶意服务器连接到SSH客户端的X服务器，而不受X11的安全限制。

X验证

有客户端连接到X服务器时需要验证。验证可通过说明直接的验证信息（在实践中，它通常意味着要使用MIT-MAGIC-COOKIE-1，要求用户将一个验证“cookie”发送到服务器中）来完成，但也可通过间接方式完成——比如，对于本地连接来说，服务器可能会基于客户端的UID允许客户端进来。

有意思的是，X 服务器会回退到间接验证方式，即使客户端已经直接说明了无效的验证数据。

X11SECURITY

X11安全机制允许用户创建magic cookies。当这些cookie用于X服务器验证时，它会限制客户端的行为。（这些cookie会阻止客户端使用不安全的X扩展并阻止访问不受限于X11 SECURITY 限制的windows，但不会阻止访问另外一个受限于X11 SECURITY限制的客户端windows。）

由于所有带有X11 SECURITY限制的magic cookies都有相应的超时规定，如果cookie在超时规定的时间内没有被使用，它就会被删除。如果能够成功验证的客户端能够间接尝试通过过期且带有X11 SECURITY限制的cookie直接验证，那么直接验证就会失败，而且X服务器就会在没有X11 SECURITY的情况下回到间接验证！

（不受信任的） X 转发

当SSH客户端连接到带有ssh-X的SSH服务器时，SSH服务器能够通过已有的且客户端转发至本地X服务器的SSH隧道创建信道。X验证的处理如下：

• 当连接至SSH服务器时，SSH客户端会在X服务器上注册一个使用期为ForwardX11Timeout（默认：20分钟）新的MIT magic cookie。这个cookie受限于X11 SECURITY限制。以下我将其称为“受限的cookie”。

• 当连接至SSH服务器时，SSH客户端会创建一个看起来像MIT magic cookie的“虚拟cookie（dummy cookie）”。它会将这个字符串发送给SSH服务器，而位于SSH服务器上的X客户端在通过SSH验证X服务器时必须发送这个虚拟cookie。

这种方法的一个明显问题在于，如果在ForwardX11Timeout规定的时间内，不存在X客户端通过SSH隧道连接至X服务器的情况，那么服务器就会忘掉cookie。如果SSH客户端允许随后创建新连接，那么X服务器就不会识别出magic cookie，并且会使用通过unix域套接字连接的UID返回简介验证，给予X客户端不带X SECURITY 限制的访问权限。正因如此，超时过期后，ssh拒绝新的X11信道请求。

问题

准确地说，问题在于，ssh并不一定要在超时过期后阻拦对X服务器的新连接——而是必须阻拦X11的验证尝试。Cookie可能会在创建X服务器连接后、X客户端发送验证请求之前仍然过期。虽然连接创建之后通常直接跟着验证，但恶意攻击者可任意将其删除。攻击如下：

1. 受害者（SSH客户端）与带有ssh-X的攻击者（SSH服务器）连接。

2. 攻击者等待19.5分钟。

3. 攻击者开启对SSH服务器的X11连接，SSH服务器要求在SSH连接上创建一个新的X11信道，SSH客户端连接至X服务器。

4. 攻击者等待1分钟，超时过期，X服务器忘记“受限的cookie”。SSH客户端不再允许新的X11信道。

5. 攻击者发送带有虚拟cookie的验证请求，SSH客户端发送带有“受限的cookie”的验证请求。

6. 攻击者与未受限于X SECURITY限制的X服务器互动。

在实际操作中，可通过在调试器下及_xcb_get_auth_info启动一些X客户端的情况下创建一分钟的延时。等1分钟过后，让程序继续运行。

影响

没有受限于X11限制的程序可以跟所有已打开的程序互动，就像这个程序就是你自己一样。例如，它能够访问所有你的所有公开终端windows并且使用XTEST扩展输入任意命令，这可能会允许SSH服务器完全攻陷任何与ssh-X连接的客户端。

修复方案

OpenSSH 6.9修复了这个问题，方法是：在SSH服务器请求一个新的X11信道时以及SSH服务器发送X11验证数据时检查超时过期。此外，由于“从一开始（off-by-one）”或时间倾斜在这里非常重要，因此MIT cookie的超时会增加一分钟，而ssh拒绝X11连接/验证尝试后超时不会发生变化。

本文由测腾代码卫士编译，不代表测腾观点，转载请注明“转自测腾代码卫士www.codesafe.cn”。