允许服务与桌面交互

Question

DC OS - Windows 2008 R2 Std

客户端操作系统- Windows XP，Windows 7

我已经通过网络策略服务器实现了安全策略，并自动启用了有线AutoConfig服务。在启用有线AutoConfig服务的同时，如果我检查“允许服务与桌面交互”的标记，它在某些Window7膝上型计算机中工作正常。

但在互联网上，它警告我，“互动服务可以显示用户界面并接收用户输入。如果允许服务与桌面交互，则该服务在桌面上显示的任何信息也将显示在交互式用户的桌面上。然后，恶意用户可以控制该服务或从交互式桌面攻击它。”

你能给我举几个例子，恶意用户如何控制服务或从交互式桌面攻击它？

Answer 1

Microsoft在2008/Vista中引入了session 0隔离。使用会话零隔离，所有Windows服务现在在会话0中运行，所有人工会话在会话1和更高版本中运行。

因此，强烈建议设计需要与桌面交互的Windows服务。设计与桌面交互的服务在技术上仍然是可能的，但强烈反对。这样做是不对的。

当Windows服务必须与桌面交互时，交互登录到人类桌面上的桌面将切换到查看会话0's桌面，这样对话框或任何需要注意的对话框就会引起注意。

现在我们有一个非常高特权的帐户，通常是本地系统，向标准用户显示一个对话框。该对话框在本地系统的上下文中运行。您让标准用户有机会利用该对话框中的某些内容，并使其在本地系统的安全上下文中执行某些操作。那就是危险所在。

Answer 2

这里的要点是Windows的消息转发机制，它允许任何进程将任何消息发送到它自己的会话中的任何窗口。如果其中一个窗口属于具有提升权限的进程，显然会带来安全风险。这类攻击被称为“粉碎攻击”，并在几年前在整个安全场景中进行了深入讨论。

由于根本原因是不可能修复的--大多数(如果不是所有为Windows编写的软件都依赖于这个功能)--因此已经决定，处理此问题的唯一方法是分段--在单个用户会话中运行的所有内容都必须在单一的安全上下文中运行。自90年代末以来，服务设计准则就一直在反映这一点，并且阻碍了在服务上下文中运行的GUI代码。在Windows中，它已经成为当务之急，在这里，您根本不能让服务与用户的桌面进行交互。

当然，这对于Windows 7也是有效的，通过检查“允许服务与桌面交互”，您将允许该服务与用户看不到的虚拟桌面进行交互。如果它修复了你的服务-好吧，随它去吧。但是，请确保您没有任何Windows机器，因为这确实会带来上述安全风险。