Уязвимости безопасности платформы .NET?

Question

Я занимаюсь исследованиями безопасности .NET. Большинство источников просто описывают механизмы безопасности .NET, но ни слова о возможных уязвимостях или вещах, о которых следует помнить. Известны ли вам проблемы безопасности на платформе .NET?

Answer 1

Основным источником проблем безопасности в мире .NET являются разработчики, использующие его. Легко писать приложения на любом фреймворке, и .NET Framework не лучше.

Кроме того, единственная серьезная проблема, о которой я могу думать, это все элементы управления, которые используют String вместо SecureString для хранения конфиденциальных данных, таких как пароли. Каждая версия .NET Framework лучше, чем предыдущая, но я думаю, что есть еще несколько общих элементов управления, которые их не используют.

SecureString можно рассматривать как строку, которая хранится в зашифрованной памяти и удаляется из памяти после использования. Поскольку строки в .NET являются неизменяемыми, любые новые строки будут храниться в памяти в общих местах, чтобы новые строки с одинаковым значением могли совместно использовать эту область памяти. Это означает, что конфиденциальные данные, хранящиеся в строке, относительно легко достать.

Answer 2

Вы можете взглянуть на Secunia . Они показывают 14 уязвимостей для .NET 2.0, ноль не исправлено.

Answer 3

Вам действительно нужно почитать отличную книгу Кейта Брауна по теме , которая является отличным началом К этому моменту 10 лет, но концепции не изменились.

Answer 4

Вот эксплойт для MS09-061 .

В моем примере я использую безопасность типа использовал союз, чтобы обойти безопасность типа. Это была не настоящая безопасность уязвимость, потому что такой союз требует полного доверия. Однако если мы можно объединить два разных делегата типы мы можем сделать то же самое и потому, что пропущенного типа проверить это было возможно.

Если вы берете TypeSafetyExploitPoC.cs и заменить метод TypeSystemHole со следующим и добавить ссылку к сборке, содержащей CombinePoCHelper.il (написано в MSIL потому что это самый простой способ написать свой MulticastDelegate подкласс, который может вызвать защищенный Метод CombineImpl).

delegate void AnotherDelegate(Union1 u2); 

    static Union1 TypeSystemHole(Union2 u2)
    {
      Union1 u1 = null;
      CombineHelper del1 = delegate { };
      AnotherDelegate del2 = delegate(Union1 u) { u1 = u; };
      del1 = (CombineHelper)CombineHelper.CombineHack(del1, del2);
      del1(u2);
      return u1;
    }

Вероятность этого снова низкая ИМХО.

Answer 5

Для очень интересного, но не обязательно пригодного для использования (поскольку вам в любом случае понадобится root-доступ), посмотрите этот доклад на Blackhat (хм, прямо сейчас) от Erez Metula использование некоторых методов для взлома .NET Framework и реализации «руткитов .NET».