Комментарии 15
А что именно? Про случай из собственной практики? Про него, собственно, рассказать больше и нечего: привилегированный системный сервис хранил коллекцию объектов, выделенных по new (динамическая память). Это коллекция сериализовывалась в GUI-процесс, запущенный от лица пользователя, вошедшего в систему. А в качестве идентификатора объекта в коллекции (GUI может давать некоторые команды на манипулирование объектами в коллекции) использовался непосредственный адрес объекта. Что, собственно, раскрывало привилегированному GUI адреса кучи привилегированного сервиса. В качестве фикса идентификатором был выбран возрастающий 64-х разрядный счетчик, который инкрементировался при создании каждого нового объекта для коллекции.
Да, оба процесса пользовательские. Криминально раскрывать адреса привилегированного процесса (работающего от лица пользователя SYSTEM) непривилегированному, который может работать и от гостя. Локальное повышение привилегий (особенно при условии запуска с отсутствием прав администратора, например — в песочнице) через уязвимый системный сервис не редкость.
Если рассматривать более конкретно, то раскрыв адрес объекта в куче процесс косвенно раскрывает расположение самой кучи в своем адресном пространстве, что работает против ASLR.
NTSTATUS NTAPI NtMultiplyByTwo(DWORD InputValue, LPDWORD OutputPointer) {
DWORD OutputValue;
if (true) { // <---!!! неопределенное поведение можно игнорировать и оптимизировать
OutputValue = InputValue * 2;
}
*OutputPointer = OutputValue;
return STATUS_SUCCESS;
}
Да, думаю автор первый (слишком примитивный) пример взял из головы, а не из собственной практики:
Утечки через неинициализированную локальную переменную на практике не очень распространены: с одной стороны современные компиляторы часто обнаруживают и предупреждают о таких проблемах, с другой стороны подобные утечки являются функциональными ошибками, которые могут быть обнаружены во время разработки или тестирования.
Ядра до Windows Vista (2003, XP, …) собирались практически без оптимизации. Возможно подобная позорная ошибка была именно в ядрах старых ОС.
В настоящее время проект самозащиты ядра (Kernel Self Protection Project) производит портирование механизма STACKLEAK в основное ядро.
Как STACKLEAK улучшает безопасность ядра Linux
На момент написания статьи (25.09.2018) 15 версия серии патчей находится в ветке linux-next, соответствует всем озвученным требованиям Линуса и готова к merge-window ядра 4.20 / 5.0.
Раскрытие памяти (Memory Disclosure) ядра в современных ОС