为什么 Windows 中的应用程序没有沙盒化?

信息安全 应用安全 视窗 沙盒
2021-09-04 09:06:36

沙盒似乎是一种限制应用程序可以做什么的方法。今天,我无法控制我的应用程序对计算机的作用。使用基于 JavaScript 的 Web 应用程序感觉比在我的 Windows 系统上运行本机应用程序更安全。

应用程序在 Windows 上默认不被沙盒化的原因是什么?

另请参阅如何限制应用程序可以对我的计算机执行的操作?

我对 Windows API 编程了解不多,但是如果被任意程序允许的话,一些函数似乎很可怕,例如:

3个回答

哦,但他们是,好先生!沙盒并不是一个新概念,自 1980 年代就已经存在。但是,正如您可能已经收集到的那样,这些沙盒类型的限制已经被推到了从安全角度来看它们看起来不够充分的地步。

关于沙盒和权限模型

让我解释。当您的计算机启动时,出于兼容性原因,它以 16 位实模式启动(即您仍然可以运行 DOS)。切入正题,您基本上切换到 32 位保护模式或 64 位长模式,它们略有不同,但也相当相似。此时,您的基于 x86 的 CPU 处于超级用户模式,并且必须设置和处理诸如页面错误和系统输入或软件中断之类的事情,以便您可以进行系统调用。跳过几百万行代码来启动你所有的硬件设备和tada,你的第一个进程运行。

您可能知道,您的进程是在对底层系统内存一无所知的情况下创建的——它看到的是虚拟内存。它也是在正常模式下创建的(称为 ring 3),这意味着它不能做诸如设置中断处理程序或更改页面标志之类的事情。简而言之,它无法看到其他进程的存在(它“相信”它已经完全运行了计算机) ,除非通过询问操作系统。

所以,你每天的平均流程沙盒化的。现在,所有进程* 必须要求操作系统执行操作,包括管理员的。决定他们能否做到的是……操作系统。

目前,这主要是通过用户权限完成的。进程继承了它们正在运行的用户的上下文;所以以管理员用户身份运行的进程可以做任何事情,因为 Windows 内核会检查它的权限,发现它是管理员并说“是的,好的”(有例外;用户模式进程在技术上不能做某些事情,但他们可以加载可以的内核模式进程(例如驱动程序)。同样,在 Linux 上,root 被认为可以做任何事情。

因此,当前模型(现在我终于解决了您的问题)说进程继承并且可以完全执行您的用户可以执行的操作。

现在这可能是一个合理的假设,除了您可能希望在磁盘上有一个敏感的 Word 文档并运行 Web 浏览器。由于您的网络浏览器可以执行用户可以执行的任何操作,因此您可以使用 word 阅读文档这一事实意味着网络浏览器也可以,如果它愿意的话,并且没有任何规定可以防止这种情况发生.

针对操作系统(例如 MAC)的更具侵入性、更多沙盒权限系统的设计这些系统都提出了不同的想法,即每个过程都受到额外的限制。因此您的网络浏览器只允许访问网络、临时存储和下载文件夹。我在这里询问了他们缺乏吸收的原因,普遍的共识似乎是复杂性是一个主要因素。人们很好地理解当前模型,即使这种理解只是“我以管理员身份运行以防止所有烦人的对话”。MAC系统本质上是复杂的;您需要了解流程应该能够做什么来约束它。

Windows Vista 实际上引入了备受诟病且令人讨厌的安全故障,其中包括许多其他出色的安全功能和某些操作系统组件的重建,强制完整性控制这些在某种程度上将 MAC 类型的组件构建到 Windows 中。

因此,对于一般问题tl;博士:MAC 难以理解且难以实现。

关于那些 API 调用

现在,进入可怕的 API 调用:

  • VirtualProtectEx:更改指定进程的虚拟地址空间中已提交页面区域的保护

  • WriteProcessMemory:将数据写入指定进程中的内存区域。要写入的整个区域必须可访问,否则操作将失败。

记下后者底部的注释:

任何拥有对要写入的进程具有 PROCESS_VM_WRITE 和 PROCESS_VM_OPERATION 访问权限的句柄的进程都可以调用该函数。通常但并非总是如此,正在调试具有正在写入的地址空间的进程。

这些全大写值是代表 Windows 权限的常量 - 只有在您拥有或可以获得进程的这些权限时,您才能调用该函数。在前一个功能上,请注意:

句柄必须具有 PROCESS_VM_OPERATION 访问权限。有关详细信息,请参阅进程安全性和访问权限。

此处讨论了完整的进程权限集现在,最需要注意的是您需要 SeDebugPrivilege。这个细节在旧新事物上得到了最好的解释

默认情况下,用户只能调试他们拥有的进程。为了调试其他用户拥有的进程,您必须拥有 SeDebugPrivilege 权限。但是不要随便授予这个特权,因为一旦你这样做了,你就放弃了农场。

所以是的,作为用户,您可以调用这些函数和调试进程,但仅限于您已经拥有的那些。由于权限模型允许您必须执行任何您的用户(包括您正在运行的进程)可以执行的任何进程,因此这是预期的。调试您自己的流程是一项合理的活动,尽管是的,它可能会被用于生病——这种能力是当前模型问题的症结所在。

现在,进入 GetKeyboardState:

应用程序可以调用此函数来检索所有虚拟键的当前状态。当线程从其消息队列中删除键盘消息时,状态会发生变化。

所有运行 GUI 的 Windows 进程都有一个发生在它们身上的事件的消息队列。这意味着您可以在读取事件后检索进程的键盘状态。但是,请注意:

状态不会随着键盘消息被发布到线程的消息队列而改变,也不会随着键盘消息被发布到其他线程的消息队列或从其他线程的消息队列中检索而改变。(例外:通过 AttachThreadInput 连接的线程共享相同的键盘状态。)

所以,是的,您可以使用 AttachThreadInput 来挂钩其他进程的输入。有一个解决方法 - 请参阅Windows 安全桌面模式如何工作?. 从本质上讲,Windows 支持多个桌面,并且通过使用这些桌面,您无法将 AttachThreadInput 附加到它们上。

tl;dr这些功能与当前安全模型相结合确实代表了当前模型的风险和局限性,尤其是对当前用户的数据和流程;但是,如果您不是以管理员用户身份运行,则您的系统作为一个整体有一定级别的安全保护

为什么应用程序在 Windows 上默认不被沙盒化?我不知道,但我猜这是以下原因的混合:

  1. 沙盒以复杂而微妙的方式破坏了许多应用程序。如果 Windows 默认开启一项新功能,甚至破坏他们的一个应用程序,用户将会不高兴。设计一个既对安全有用又不会破坏任何遗留应用程序的默认沙盒方案是非常非常困难的。

  2. 历史惯性。Windows 从来没有这样做过,这将是一个重大的变化。

  3. 可理解性:沙盒会导致令人困惑且难以调试的故障。它增加了系统管理员的复杂性和认知负担,并可能导致系统管理员发现难以修复的更多崩溃或故障,从而使系统管理员不满意。

为了获得这方面的实际经验,我建议您研究一下 Apple 要求所有通过 Mac App Store 销售的应用程序都必须经过沙盒处理的举措。苹果遇到了一些困难,因此推迟了截止日期,并且有报道称某些应用程序将遭受严重的功能损失。这是开发人员合作并准备修改其应用程序以符合沙盒要求的最佳情况。现在想象一下,如果微软在 Windows 上默认将它部署到所有未修改的遗留应用程序,情况会更糟。

对沙盒有各种批评:

  • 它会诱使用户产生虚假和自满的安全感,但不会阻止恶意软件的传播(使用漏洞利用或社会工程)
  • 它使良性用户的生活更加困难,同时无法阻止合格的黑客和开发人员的错误
  • 数据所有者不能随意随意处理数据;
  • 它扼杀了创新
  • 在单独的平台上实现是没有意义的
  • 它将问题的注意力转移到错误的方向(从本质上是犯罪和社会问题到技术问题)

更新
相关文章: