.net - 为什么 .NET 不验证 BCL/CLR？

Question

BCL 和 CLR(以后只使用 CLR)中的所有 .NET 程序集都是 strongly named and digitally signed .提供数字证书是为了确保程序集未被篡改或更换的信任度。但是，.NET 似乎从未检查过数字签名(它可以检查强名称为 Hans pointed out)。

检查程序集负载存在缺陷是有道理的，因为修改后的 CLR 可能会伪造答案。我的想法是，从 .NET1 的角度来看，唯一要检查的安全位置是在框架的启动时作为引导框架的非托管代码的一部分。最大的缺点是性能影响。

我是从开发人员的角度来看这个问题的，换句话说，我怎么知道我的应用程序没有受到已经拥有的 CLR2 的危害，或者换句话说，应用程序是否可以信任 CLR？

所以我的问题是为什么 .NET 不验证 CLR？是因为性能影响还是其他原因？

1. 我专注于 .NET，可能会弄乱 Windows 从而打破这个想法，但如果您已经拥有 Windows，您就不需要拥有 .NET。
2. 例如，用户在应用程序中输入密码，密码存储在 SecureString 中，但 BCL 被破坏，因此攻击者现在可以获取该信息。它允许他们捕获其他信息。我意识到如果攻击者可以更换 CLR，他也可以在机器上放置一个键盘记录器，但是(希望)可以用一个像样的安全工具检测到。还有很多其他的方法可以解决这个问题，核心是我如何知道 SecureString 是否已更改。

Answer 1

这在 .NET 3.5 SP1 中已更改，旨在作为 startup perf improvement对于完全信任运行的应用程序，让它们与不进行此类检查的 native 程序相同。验证强名称的成本很高，而且由于 DLL 数量众多，托管程序的冷启动往往很慢。您可以使用 .config 文件重新打开它:

<configuration>
    <runtime>
        <bypassTrustedAppStrongNames enabled="false"/>
    </runtime>
</configuration>

或者通过编辑注册表项使其对所有 .NET 程序有效:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
"AllowStrongNameBypass"=dword:00000000

还要在 64 位机器上设置 HKLM\Software\Wow6432Node 键。