我正在使用 Windows 10。
windbg -kl首次安装 Windows 时，默认禁用本地内核调试 ( )。要启用它，您必须运行bcdedit -debug on并重新启动。（不过，据我所知，即使本地内核调试被禁用，Sysinternals LiveKd 似乎也能正常工作。）
为什么默认禁用本地内核调试？始终启用它有什么缺点吗？
问问题
1583 次
1 回答
4
如评论中所述，默认情况下禁用内核调试，因为它允许（即使在 64 位 Windows 上）加载非真正签名（自签名）的内核驱动程序。（并禁用 PatchGuard 等）
当然，关于“管理员仍然生活在用户空间中”的评论是无稽之谈。评论者应该继续阅读Raymond Chen关于“在这个密闭 舱口的另一边 ”的帖子。请允许我用他的话：
我想你知道这个故事的结局。如果您有管理员权限，那么您已经在密闭舱口的另一边。您可以使用管理员权限来 pwn 这台机器并不有趣，因为作为管理员，您已经 pwn 了这台机器。
管理员和系统之间在形式上是有区别的，因为它们是一些经过 ACL 处理的事情，因此 SYSTEM 可以执行它们而不是任意管理员，但是这种区别是正式的而不是实际的。想要让某些代码以 SYSTEM 身份运行的管理员可以安装以 SYSTEM 身份运行的服务。或者使用 Debug Privilege 接管作为 SYSTEM 运行的进程（例如，服务）。或者只需以 SYSTEM 身份打开命令提示符并前往城镇。无需通过复杂的操作 Q 来获得 SYSTEM 访问权限。
如果您将 SYSTEM 替换为内核模式驱动程序，则第一句话成立。
您在删除的评论中说管理员可以加载驱动程序是正确的，但在 x64 上必须对其进行签名。
能够加载未签名的驱动程序为您节省的不是 75 美元或填写在线表格，而是提供可证明的身份。内核模式代码签名证书与域验证 SSL 证书不同。
请注意，Microsoft打算要求内核模式驱动程序经过 WHQL 认证（或使用“证明签名”，据说仅在非服务器 SKU 上），这需要将驱动程序提交给 Microsoft，并使用 EV 证书打开 Windows 硬件开发人员帐户. 嘿！那是怎么回事？这是与 CA 勾结，让我们为证书支付更多费用的阴谋吗？也许。也许他们想确定你的身份，并将验证委托给 CA（假设 EV 做了它应该做的事情）。
安全方面，这并没有建立真正的安全边界，而是一种温和的缓解措施。但还有其他考虑：微软不希望软件发行商安装糟糕的驱动程序，从而使 Windows 随他们一起瘫痪。而且，如果他们碰巧这样做了，微软想知道是谁编写了这些驱动程序。这就是证明签名背后的基本原理。
如果您可以轻松启用内核调试，您可以打赌，一些二流 ISV 会编写糟糕的驱动程序，而无需费心对其进行测试或签名，并且会使用该 hack 安装它。（实际上，我今天知道一些不那么糟糕的 ISV，他们签署了他们的驱动程序但没有 WHQL 认证他们，并使用黑客在没有任何提示的情况下安装它们。这是真实的。）
当然，同样糟糕的 ISV 可以在其安装程序（运行提升）中启用内核调试，并且可以在下次重新启动后加载其驱动程序。但是桌面上有一条烦人的消息说你正在测试签名模式下运行以保护你免受这种情况的影响。当然，同样糟糕的 ISV 可以四处乱窜并隐藏消息，但此时获取证书可能更容易。这并不能阻止任何事情，但它通过使它变得足够烦人来提供缓解，这样他们就不会打扰。
如果您想知道为什么启用内核调试会使您进入测试签名模式，答案是：因为这是通常的预期场景。即使在内核调试时，您也可以更改注册表值以要求生产签名，但这是例外情况。对于常见场景，默认值是正确的。你有 LiveKD。微软没有理由向后弯腰来处理一个没有真正发生的场景。他们有足够的问题。就像在 Microsoft Edge 中修复所有这些崩溃一样。
于 2017-03-20T23:27:29.660 回答