Aslr что это

Внутреннее устройство ASLR в Windows 8

ASLR — это Address Space Layout Randomization, рандомизация адресного пространства. Это механизм обеспечения безопасности, который включает в себя рандомизацию виртуальных адресов памяти различных структур данных, чувствительных к атакам. Расположение в памяти целевой структуры сложно предугадать, поэтому шансы атакующего на успех малы.

Реализация ASLR в Windows тесно связана с механизмом релокации (relocation) исполняемых образов. Релокация позволяет PE-файлу загружаться не только по фиксированной предпочитаемой базе. Секция релокаций в PE-файле является ключевой структурой при перемещении образа. Она описывает, какие необходимо внести изменения в определенные элементы кода и данных для обеспечения корректного функционирования приложения по другому базовому адресу.

Ключевую роль в работе ASLR играют генератор случайных чисел и пара функций, модифицирующих базовый адрес загружаемого PE-файла.

Windows 8 полагается на генератор случайных чисел, который по сути является генератором Фибоначчи с задержкой с параметрами j=24 и k=55. Его зерно инициализируется в модуле winload.exe при старте системы. Winload.exe собирает энтропию из различных источников: ключи реестра, TPM, текущее время, ACPI, а также при помощи новой инструкции rdrand. Инициализация ядерного генератора случайных чисел детально описана в источнике [1].

Рассмотрим подробнее новую инструкцию rdrand. В процессорах, основанных на архитектуре Ivy Bridge, была представлена технология Intel Secure Key для генерации высококачественных псевдослучайных чисел. Она реализована при помощи аппаратного цифрового генератора случайных чисел (DRNG) и инструкции rdrand для программного извлечения значений из него.

С аппаратной точки зрения DRNG представляет собой отдельный модуль на процессорном чипе. Он работает асинхронно с ядрами процессора на частоте 3 ГГц. DRNG использует тепловой шум в качестве источника энтропии; кроме того, в нем присутствует встроенная система тестирования, выполняющая серию проверок качества извлекаемых случайных значений. В случае неудовлетворительного результата тестирования, DRNG перестает генерировать случайные значения.

Для извлечения случайных чисел из DRNG используется инструкция rdrand. В документации к ней отмечено, что теоретически DRNG может возвращать нулевые значения в случае неудовлетворительного результата тестирования или опустошения внутренней очереди случайных значений. Однако на практике опустошить DRNG не удалось.

Intel Secure Key является мощным генератором случайных чисел, производящим высококачественные случайные значения с очень высокой скоростью. Практически невозможно предугадать изначальное состояние генератора, инициализированного при помощи инструкции rdrand (в отличие от прочих источников энтропии).

Внутренней интерфейсной функцией ядерного ГПСЧ является ExGenRandom(). Она также имеет экспортируемую функцию-обертку RtlRandomEx(). ASLR в Windows 8 использует ExGenRandom() — в отличие от предыдущих версий, которые полагались на инструкцию rdtsc. Последняя используется для получения счетчика времени на ЦПУ, который изменяется линейно и, следовательно, не может обеспечить должного качества генерируемых значений, что небезопасно.

Основной функцией механизма ASLR является MiSelectImageBase(). В Windows 8 она может быть описана следующим псевдокодом.

#define MI_64K_ALIGN(x) (x + 0x0F) >> 4 #define MmHighsetUserAddress 0x7FFFFFEFFFF typedef PIMAGE_BASE ULONG_PTR; typedef enum _MI_MEMORY_HIGHLOW < MiMemoryHigh = 0, MiMemoryLow = 1, MiMemoryHighLow = 2 >MI_MEMORY_HIGHLOW, *PMI_MEMORY_HIGHLOW; MI_MEMORY_HIGHLOW MiSelectBitMapForImage(PSEGMENT pSeg) < if (!(pSeg->SegmentFlags & FLAG_BINARY32)) // WOW binary < if (!(pSeg->ImageInformation->ImageFlags & FLAG_BASE_BELOW_4GB)) < if (pSeg->BasedAddress > 0x100000000) < return MiMemoryHighLow; >else < return MiMemoryLow; >> > return MiMemoryHigh; > PIMAGE_BASE MiSelectImageBase(void* a1, PSEGMENT pSeg) < MI_MEMORY_HIGHLOW ImageBitmapType; ULONG ImageBias; RTL_BITMAP *pImageBitMap; ULONG_PTR ImageTopAddress; ULONG RelocationSizein64k; MI_SECTION_IMAGE_INFORMATION *pImageInformation; ULONG_PTR RelocDelta; PIMAGE_BASE Result = NULL; // rsi = rcx // rcx = rdx // rdi = rdx pImageInformation = pSeg->ImageInformation; ImageBitmapType = MiSelectBitMapForImage(pSeg); a1->off_40h = ImageBitmapType; if (ImageBitmapType == MiMemoryLow) < // 64-bit executable with image base below 4 GB ImageBias = MiImageBias64Low; pImageBitMap = MiImageBitMap64Low; ImageTopAddress = 0x78000000; >else < if (ImageBitmapType == MiMemoryHighLow) < // 64-bit executable with image base above 4 GB ImageBias = MiImageBias64High; pImageBitMap = MiImageBitMap64High; ImageTopAddress = 0x7FFFFFE0000; >else < // MiMemoryHigh 32-bit executable image ImageBias = MiImageBias; pImageBitMap = MiImageBitMap; ImageTopAddress = 0x78000000; >> // pSeg->ControlArea->BitMap ^= (pSeg->ControlArea->BitMap ^ (ImageBitmapType ControlArea.BitMap = ImageBitmapType; RelocationSizein64k = MI_64K_ALIGN(pSeg->TotalNumberOfPtes); if (pSeg->ImageInformation->ImageCharacteristics & IMAGE_FILE_DLL) < ULONG StartBit = 0; ULONG GlobalRelocStartBit = 0; StartBit = RtlFindClearBits(pImageBitMap, RelocationSizein64k, ImageBias); if (StartBit != 0xFFFFFFFF) < StartBit = MiObtainRelocationBits(pImageBitMap, RelocationSizein64k, StartBit, 0); if (StartBit != 0xFFFFFFFF) < Result = ImageTopAddress - (((RelocationSizein64k) + StartBit) BasedAddress - a1->SelectedBase)) < GlobalRelocStartBit = MiObtainRelocationBits(pImageBitMap, RelocationSizein64k, StartBit, 1); StartBit = (GlobalRelocStartBit != 0xFFFFFFFF) ? GlobalRelocStartBit : StartBit; Result = ImageTopAddress - (RelocationSizein64k + StartBit) a1->RelocStartBit = StartBit; a1->RelocationSizein64k = RelocationSizein64k; pSeg->ControlArea->ImageRelocationStartBit = StartBit; pSeg->ControlArea->ImageRelocationSizeIn64k = RelocationSizein64k; return Result; > > > else < // EXE image if (a1->SelectedBase != NULL) < return pSeg->BasedAddress; > if (ImageBitmapType == MiMemoryHighLow) < a1->RelocStartBit = 0xFFFFFFFF; a1->RelocationSizein64k = (WORD)RelocationSizein64k; pSeg->ControlArea->ImageRelocationStartBit = 0xFFFFFFFF; pSeg->ControlArea->ImageRelocationSizeIn64k = (WORD)RelocationSizein64k; return ((DWORD)(ExGenRandom(1) % (0x20001 - RelocationSizein64k)) + 0x7F60000) > ULONG RandomVal = ExGenRandom(1); RandomVal = (RandomVal % 0xFE + 1) BasedAddress - a1->SelectedBase; if (RelocDelta > MmHighsetUserAddress) < return 0; >if ((RelocationSizein64k MmHighsetUserAddress) < return 0; >if (RelocDelta + (RelocationSizein64k if (RelocDelta + (RelocationSizein64k MmHighsetUserAddress) < return 0; >if (a1->SelectedBase + RandomVal == 0) < Result = pSeg->BasedAddress; > else < if (RelocDelta >RandomVal) < Result = RelocDelta - RandomVal; >else < Result = RelocDelta + RandomVal; if (Result < RelocDelta) < return 0; >if (((RelocationSizein64k 0x7FFFFFDFFFF) < return 0; >if (((RelocationSizein64k > > //random_epilog a1->RelocStartBit = 0xFFFFFFFF; a1->RelocationSizein64k = RelocationSizein64k; pSeg->ControlArea->ImageRelocationStartBit = 0xFFFFFFFF; pSeg->ControlArea->ImageRelocationSizeIn64k = RelocationSizein64k; return Result; > 

Как можно заметить, существуют три различные битовые карты образов. Первая предназначена для 32-разрядных исполняемых приложений, вторая — для 64-разрядных, третья — для 64-разрядных приложений с базой выше 4 ГБ, что дает им виртуальный адрес с высокой энтропией.

Рандомизация исполняемых образов влияет непосредственно на их базовый адрес. В случае загрузки библиотек, ASLR является частью процесса релокации модуля: случайной величиной при выборе нового базового адреса является переменная ImageBias, которая инициализируется при старте системы.

VOID MiInitializeRelocations()

Битовые карты исполняемых образов отображают адресное пространство текущих пользовательских процессов. Исполняемый образ получает базовый адрес во время загрузки, его повторная загрузка в другие процессы будет производиться по тому же базовому адресу. Такое поведение загрузчика является наиболее эффективным в смысле быстродействия и экономии памяти благодаря использованию исполняемыми образами механизма копирования при записи (copy-on-write).

Текущая реализация ASLR в Windows 8 позволяет рандомизировать базовый адрес приложений, не поддерживающих рандомизацию. Ниже приведена таблица, демонстрирующая поведение загрузчика в зависимости от комбинаций флагов линкера, связанных с ASLR.

* Невозможно собрать образ при помощи MSVS, поскольку флаг /DYNAMICBASE требует флаг /FIXED:NO, который генерирует секцию релокаций

Можно заметить изменение в поведении загрузчика, характерное для Windows 8: если исполняемый образ имеет секцию релокаций, то он будет загружен в любом случае. Это еще одно свидетельство взаимосвязи между ASLR и механизмом релокации

В целом можно сказать, что реализация новых функций ASLR в Windows 8 не оказывает значительного влияния на логику кода, поэтому достаточно сложно обнаружить в ней полезные уязвимости. Увеличение энтропии для рандомизации различных объектов по сути является заменой константного выражения в коде. Кроме того, по графам кода можно отметить проведение инспекции кода.

Источники
[1] Valasek Ch., Mandt T. Windows 8 Heap Internals. 2012.
[2] Johnson K., Miller M. Exploit Mitigation Improvements in Windows 8. Slides, Black Hat USA, 2012.
[3] Intel. IntelDigital Random Number Generator (DRNG): Software Implementation Guide. Intel Corporation, 2012.
[4] Whitehouse O. An Analysis of Address Space Layout Randomization on Windows Vista. Symantec Advances Threat Research, 2007.
[5] Sotirov A., Dowd M. Bypassing Browser Memory Protections. 2008.

Авторы: Артем Шишкин (honorarybot) и Илья Смит (blackzert), исследовательский центр Positive Research.

• Блог компании Positive Technologies
• Информационная безопасность

Защита от атаки ASLR в Windows

Windows 8, Windows 8.1 и последующие версии Windows не могут правильно применить настройку ASLR, что делает эту важную функцию безопасности Windows совершенно бесполезной. В этой статье я покажу как включить защиту от атак ASLR, добавив небольшое изменение в реестре.

Что такое ASLR

Рандомизация размещения адресного пространства (ASLR) — это технология, применяемая в операционных системах, при использовании которой случайным образом изменяется расположение в адресном пространстве процесса важных структур данных, а именно образов исполняемого файла (Wikipedia).

В первые ASLR появилась в OpenBSD, в далеком 2003 году, и с тех пор она была добавлена ​​во все популярные операционные системы, включая Linux, Android, MacOS и Windows.

Microsoft добавила ASLR в Windows с выпуском Vista в 2006 году. Чтобы включить эту функцию, пользователям пришлось установить Microsoft EMET и использовать ее графический интерфейс для включения ASLR в общесистемных и / или конкретных приложениях.

С выпуском Windows 10 ASLR был добавлен в «Центр безопасности защитника Windows», и теперь пользователи могут включить его в разделе «Управление приложениями и браузером», а затем «Параметры защиты от эксплойтов».

ASLR в Windows

Изучая недавно обнаруженную 17-летнюю уязвимость, влияющую на редактор формул Microsoft Office, специалист в области информационной безопасности Уилл Дорманн обнаружил, что в определенных условиях ASLR не рандомизировала местоположения объектов в памяти.

Согласно Dormann, включение общесистемной защиты ASLR, приводит к ошибке в реализации этой функции в Windows. Исследователь говорит, что эта проблема затрагивает только Windows 8 и более поздние версии, поскольку Microsoft изменила значения реестра, с помощью которых включается ASLR.

Защита от атаки ASLR в Windows

Ожидается, что Microsoft в будущем патче исправит данную проблему. В настоящее же время единственным способом активации функции ASLR на Windows является ручное изменение реестра Windows.

Ниже приведен легкий, временный способ защититься от атаки ASLR:

Создайте пустой текстовый файл и введите следующий текст:

Aslr что это

Мы недавно сообщает об уязвимости ASLR, обнаруженной исследователем безопасности по имени Уилл Дорманн из Университета Карнеги-Меллона.

И EMET, и Exploit Guard в Защитнике Windows включают общесистемный ASLR, но не включают общесистемный ASLR снизу вверх. Хотя защита от эксплойтов в Защитнике Windows имеет общесистемный параметр для общесистемного восходящего ASLR, значение графического интерфейса по умолчанию «Включено по умолчанию» не отражает базовое значение реестра (не задано). Это приводит к перемещению программ без /DYNAMICBASE, но без какой-либо энтропии. Результатом этого является то, что такие программы будут перемещены, но по одному и тому же адресу каждый раз при перезагрузке и даже в разных системах.

Но в ответ на претензии Дорманна Мэтт Миллер из Microsoft говорит об этом в своем блоге под названием Уточнение поведения обязательного ASLR :

Короче говоря, ASLR работает так, как предполагалось, и проблема с конфигурацией, описанная CERT/CC, затрагивает только те приложения, в которых EXE еще не использует ASLR. Проблема с конфигурацией не является уязвимостью, не создает дополнительных рисков и не ослабляет существующий уровень безопасности приложений.

CERT/CC выявила проблему с интерфейсом конфигурации Exploit Guard в Защитнике Windows (WDEG), которая в настоящее время не позволяет общесистемному включению восходящей рандомизации. Команда WDEG активно исследует это и примет соответствующие меры.

ASLR или рандомизация адресного пространства используется для рандомизации адресов памяти, используемых исполняемыми файлами и файлами DLL, чтобы злоумышленник не мог воспользоваться переполнением памяти.

Технология ASLR некорректно работает в операционных системах Microsoft, начиная с Windows 8

Рекомендуем почитать:

Xakep #293. MikroTik Nightmare

• Содержание выпуска
• Подписка на «Хакер» -60%

Специалист координационного центра CERT (CERT/CC) Уилл Дорманн (Will Dormann) обнаружил, что в ряде случаев защитный механизм Address Space Layout Randomisation (ASLR) работает некорректно, причем проблема появилась еще во времена Windows 8 и сохраняется по сей день, после релиза Windows 10.

Напомню, что ASLR (Address Space Layout Randomization или рандомизация размещения адресного пространства) – это защитный механизм, поддерживаемый практически всеми современными операционными системами, включая Windows, Linux, macOS, iOS и Android. По сути, ASLR случайным образом изменяет расположение в адресном пространстве различных важных структур данных: образов исполняемых файлов, подгружаемых библиотек, хипа и так далее. Дело в том, что зачастую для успешной реализации атаки злоумышленнику необходимо знать, где именно в адресном пространстве происходит выполнение кода того или иного приложения, а ASLR призван защитить систему от таких атак.

Исследователь CERT/CC объясняет, что начиная с релиза Windows 8 общесистемная имплементация ASLR (system-wide mandatory), так же известная как принудительный ALSR (Force ASLR), имеет нулевую энтропию, то есть, по сути, рандомизация размещения адресного пространства не производится, и релокация исполняемых файлов осуществляется по одному и тому же адресу. Напомню, что данная функция активируется через EMET, а с недавних пор, после выхода Windows 10 Fall Creators Update, она стала частью Windows Defender Exploit Guard. Force ASLR призвана осуществлять рандомизацию даже в тех случаях, когда поддержка ASLR не включена для конкретного приложения.

Специалисты Microsoft уже ответили на опубликованный Дорманном доклад, сообщив, что тот обнаружил проблему, которую вряд ли можно назвать полноценной уязвимостью. Дело в том, что, по словам инженеров Microsoft, все отнюдь не так плохо. ASLR в Windows 8 и 10 работает как должно в 11 случаях из 12, а описанные исследователем проблемы могут возникать крайне редко, исключительно в силу нюансов конфигурации. Свои слова инженеры Microsoft подкрепили наглядной иллюстрацией: в таблице ниже проблема обозначена желтым цветом.

Представители Microsoft согласились с предложенными Дорманном вариантами решения проблемы, и описывают в блоге шаги, которые могут предпринять пользователи. К примеру, пока не выйдет официальный патч, можно внести небольшие поправки в системный реестр.