OpenSSH <=6.8 X11版本安全BUG

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

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

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

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

   当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。以下是蹩脚的一些ASCII信息流：

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

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

[]受害者（SSH客户端）与带有ssh-X的攻击者（SSH服务器）连接.[/][]攻击者等待19.5分钟.[/][]攻击者开启对SSH服务器的X11连接，SSH服务器要求在SSH连接上创建一个新的X11信道，SSH客户端连接至X服务器.[/][]攻击者等待1分钟，超时过期，X服务器忘记“受限的cookie”。SSH客户端不再允许新的X11信道.[/][]攻击者发送带有虚拟cookie的验证请求，SSH客户端发送带有“受限的cookie”的验证请求.[/][]攻击者与未受限于X SECURITY限制的X服务器互动.[/]

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

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