.NET中新運算符和委托的安全性內部

Question

前段時間我讀到了有關C / C ++的各種安全建議。 之后我開始思考他們是否適用於.NET我找到了一些答案，但並非所有答案都是如此，所以這里是我的問題。

建議使用HeapAlloc方法而不是VirtualAlloc來分配內存。 我知道VirtualAlloc有兩個潛在的問題。 首先，在Windows 8之前，ASLR（地址空間布局隨機化）不會隨機分配由此函數分配的地址。 其次， VirtualAlloc允許使用固定的基址分配內存，這也是不建議的，因為使寫入漏洞更容易。 有關詳細信息，請參閱本文 。

問題是新操作員如何在引擎蓋下工作？ 它是否使用HeapAlloc ， VirtualAlloc或其他東西？

還建議不要直接使用函數指針，而是在需要時使用EncodePointer / DecodePointer函數對它們進行模糊處理和去模糊處理 。 這是一個與ASRL類似的概念。 這種技術的目標是難以預測指針值並覆蓋它，以便它指向一些惡意代碼。 我們在.NET中有委托，但我認為在幕后.NET必須在某些時候使用函數指針。

問題是.NET內部使用的函數指針的地址是否被混淆了？

Answer 1

細節相當模糊，我不會花很多時間尋找攻擊.NET進程的方法:)我所知道的是：

• .NET程序集啟用了/ DYNAMICBASE選項，與本機程序用於啟用ASLR的選項相同。
• .NET程序集默認啟用/ HIGHENTROPYVA選項。 C＃編譯器公開/ highentropyva編譯器選項來控制它。
• CLR僅使用VirtualAlloc（）進行分配。 它通過隨機化appdomain的加載器堆（jitted代碼，靜態，類型等）和GC堆段的地址來實現自己的ASLR品牌。 每次運行程序都會發生這種情況。 線程堆棧也是隨機的，可能是因為之前的選項。
• 異常過濾器位於表查找中，而不是堆棧上的指針。 與/ SAFESEH相同
• .NET程序中的本機代碼（jitter，CLR，CRT）自.NET 4.0開啟/ GS后，檢測到堆棧粉碎嘗試。

沒有EncodePointer（）調用，我懷疑他們可以工作。 我從來沒有聽說過對.NET程序的成功攻擊，用惡意數據感染托管代碼是一個非常高的命令。 但誰知道呢。 多年來已經有相當多的安全更新，所以有人想出了一些東西 :)

Answer 2

所有這些僅適用於您使用不安全的代碼或PInvoke（也需要完全信任）。 對於安全的托管代碼，此問題不適用，因為CLR的指定方式使您無法破壞內存安全性。 因此，通過隨機化地址可以防止任何利用。 地址不會以安全的托管代碼（以任何可用的方式）公開。

托管代碼new （與native new相對）使用托管堆。 使用VirtualAlloc從操作系統獲取堆內存。 我不知道它的位置是否隨機化。 並非每個new調用都會導致新的OS分配。 許多對象適合一個OS分配。

delegate確實是一個功能指針。 它沒有被混淆（大概是出於性能原因）。 大多數代表指向代碼堆上的jitted代碼，可能是使用VirtualAlloc分配的（或者在NGEN使用時通過LoadLibrary加載）。

.NET假定您的進程沒有被攻擊者能夠寫入任意字節的“黑客”攻擊。 如果是這種情況，則所有安全保證都不在窗口內。

因此，我發現你提出的問題並不特別重要。 這是一個深度安全的問題，這個問題很好但不是必需的。