none
Серьезная проблема безопасности SecurityCritical/SecurityTransparent RRS feed

  • Вопрос

  • Дубль с английской версии сообщения: http://social.msdn.microsoft.com/Forums/ru-RU/netfxbcl/thread/690ff1b5-45fa-49a4-bf9f-a7e6b379e058

    Суть проблемы простая и от этого особенно плохая. В документации к .NET4.0 четко сказано, что транспарентный код не имеет полномочий на выполнение рефлексии относительно SecurityCritical кода.

    В свое время с .NET 2.0 была проведена миграция кода на .NET 4.0.

    В проекте серьезное место занимает безопасность. Среди прочего при помощи CAS была проведена настройка, не допускавшая рефлексии со стороны недоверенного кода. Этим защищались ключевые классы безопасности ядра.

    С приходом .NET 4 мы естественно перешли на SecurityCritical, SecuritySafe и SecurityTransparent резонно полагая (как следовало из документации по миграции), что это автоматически блокирует не только обычные вызовы защищенного кода из "прозрачных" сборок, но и (само собой) не допускает рефлексии.

    И вот недавно мы для демонстрации отличной безопасности, которую нам Run-Time дает .NET написали плагин-эксплойт, с целью показать, что даже используя знания о внутреннем устройстве ядра приложения нельзя неверно написанным или троянским плагином дескредитировать сами алгоритмы безопасности. А на деле оказалось, что только нормальный код и проверяется на соответствие политикам, а "хакерский" эксплойт спокойно меняет [SecurityCritical]private static readonly SECURETYPE __secureField поля...

    Чтобы это проверить достаточно:

    Создать сборку core.dll  и в ней определить такой например класс:

    static class VerySecretClass {

             [SecurityCritical]private static readonly int __secureField = 155;

    }

    Создать сборку exploit.dll и в ней

    [assembly:SecurityTransparent] //да пожалуйста!!!

    class Exploit(){

         void Hello_Crack(){

         var fld = typeof(VerySecretClass).GetField("__secureField", BinfingFlags..(static,nonpublic,getfield));

    /// WOW!!! I 've GOT IT!!!

         fld.SetValue(null, 312432432);

    ///WOW, I've DONE IT;

    }

    }

    Мне эта ситуация совершенно не нравится. Получается что вся модель безопасности кода - колосс на глиняных ногах, который защищает систему только от "белого" кода, а для злонамеренного и просто небезопасного кода все ворота открыты нараспашку.

    Уверен, что подобная ситуация должна быть закрыта как можно скорее.

    Конфигурация - .NET 4.0 + апгрейд 4.5 (для EntityFramework)

    11 октября 2012 г. 5:03

Ответы

Все ответы