Question

BCL＆amp;中的所有.NET程序集CLR（仅使用CLR）都是strongly named and digitally signed。提供数字证书是为了给予组件未被篡改或替换的信任度。但是，.NET似乎没有检查数字签名（它可以将强名称检查为Hans pointed out）。

检查装配负载是有缺陷的，因为修改后的CLR可以伪造答案。我的想法是，从.NET ¹的角度来看，唯一安全的地方是框架的启动，作为启动绑定框架的非托管代码的一部分。最大的缺点是性能影响。

我从开发人员的角度来看这个问题，换句话说，我怎么知道我的应用程序没有被已经拥有的CLR ²所破坏，或者换句话说是另一种方式一个信任CLR的申请？

所以我的问题是为什么.NET不验证CLR？是因为性能影响还是更多呢？

1.我专注于.NET，有可能弄乱Windows并因此打破了这个想法但是如果你已经拥有Windows，那么你真的不需要拥有.NET。
2.示例是用户输入密码到应用程序，它存储在SecureString中，但BCL受到攻击，因此攻击者现在正在获取该信息。它允许他们捕获其他信息。我意识到攻击者是否可以替换CLR也可以在机器上放置一个关键记录器，但是（希望）可以用一个不错的安全工具检测到。还有很多其他攻击方法，核心是如何知道SecureString是否已被更改。

Answer 1

这在.NET 3.5 SP1中已更改，旨在作为startup perf improvement用于完全信任的应用程序，以使它们与不执行此类检查的本机程序进行奇偶校验。验证强名称是昂贵的，并且由于大量的DLL，托管程序的冷启动往往很慢。您可以使用.config文件重新打开它：

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

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

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

还在64位计算机上设置HKLM \ Software \ Wow6432Node密钥。

Answer 2

他们在GAC。任何可以惹恼GAC的人都已成为特权用户。此外，大多数应用程序都以完全信任模式运行，无论如何这都是无关紧要的。因为在完全信任的应用程序中，您可以使用指针，native-interop，...所有这些都可以破坏基于验证的安全性。

在执行较低信任代码的情况下（例如在Silverlight中），代码验证非常重要。在这样的沙箱中，您只想执行：

已验证安全的不受信任的代码
可信代码，可以是GAC中的代码，也可以是您信任的密钥签名。

此示例是用户输入密码到应用程序，它存储在SecureString中，但BCL受到攻击，因此攻击者现在正在获取该信息。它允许他们捕获其他信息。我意识到攻击者是否可以替换CLR也可以在机器上放置一个关键记录器，但是（希望）可以用一个不错的安全工具检测到。

此处您的安全模型已经破损。在这种威胁情形中，有很多方法可以攻击您的应用程序，而您无需关心BCL。例如，攻击者可以修补NGen ed或JITed代码。要么直接挂钩到SecureString方法，要么挂入输入处理代码。他可以使用各种密钥记录或消息拦截功能，这在我的经验中很少被发现。他可以将你的窗口子类化。您可以完全替换您的GUI。他可以简单地替换磁盘上的所有程序集。不太可能是用户会注意到的。

根据我的经验，大多数安全工具甚至不关心应用程序是否安装了低级键盘钩子，这是键入日志的最简单方法之一。

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

2 个答案: