Pull to refresh

Comments 15

Интересный материал. Я даже не задумывался, что паддинг в структурах может способствовать утечке данных.
Я про union тоже не задумывался
(Автору) Было бы интересно почитать более развернутое описание раздела «От переводчика»

А что именно? Про случай из собственной практики? Про него, собственно, рассказать больше и нечего: привилегированный системный сервис хранил коллекцию объектов, выделенных по new (динамическая память). Это коллекция сериализовывалась в GUI-процесс, запущенный от лица пользователя, вошедшего в систему. А в качестве идентификатора объекта в коллекции (GUI может давать некоторые команды на манипулирование объектами в коллекции) использовался непосредственный адрес объекта. Что, собственно, раскрывало привилегированному GUI адреса кучи привилегированного сервиса. В качестве фикса идентификатором был выбран возрастающий 64-х разрядный счетчик, который инкрементировался при создании каждого нового объекта для коллекции.

Системный? По new? Где-то тут ошибка!
Предполагаю, что оба процесса в user space. Тогда ничего особо криминального нет, и понятно, что вы напрямую доступ по этим адресам не могли получить, адресные пространства разные, virtual memory потому что.

Да, оба процесса пользовательские. Криминально раскрывать адреса привилегированного процесса (работающего от лица пользователя SYSTEM) непривилегированному, который может работать и от гостя. Локальное повышение привилегий (особенно при условии запуска с отсутствием прав администратора, например — в песочнице) через уязвимый системный сервис не редкость.

Если рассматривать более конкретно, то раскрыв адрес объекта в куче процесс косвенно раскрывает расположение самой кучи в своем адресном пространстве, что работает против ASLR.

Я понимаю, что это потенциальная дыра, но, зная только адреса в куче, из user space получить доступ к памяти процесса _без других_ утечек… Что-то навскидку не придумывается

Да, как и приведенный в пример в статье CVE-2015-2433: утечка только раскрывает адрес win32k.sys. Но именно эта уязвимость стала одним из звеньев в 0-day цепочке по локальному повышению привилегий.

Вообще говоря, Листинг 1, вполне может превратиться в
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.
Sign up to leave a comment.

Articles