#многоходовая комбинация: Dowd’s Inhuman Flash Exploit
Некто Mark Dowd из IBM описал на 25 страницах статьи Application-Specific Attacks: Leveraging the ActionScript Virtual Machine как возможно эксплуатировать уязвимость в Flash Player, который в одном месте не проверяет удачность попытки выделения памяти.
Если описать сделанное им кратко, то получается примерно следующее:
Тут важно отметить, что подмена делается аккуратно, shellcode получает подмененный адрес возврата и может завершиться нормально, не вызывая падения Flash Player'а, т.е. незаметно для пользователя.
Вообщем я нахожусь в легком шоке от изящности сей махинации..
--
1 - На эти числа есть ограничения, но подробнее о них вы можете прочитать в самой статье;
2 - ABC - это байткод, который исполняется виртуальной ActionScript машиной. Верификатор проверяет некоторые свойства кода переданного на вход виртуальной машины, например, типы операндов и что самое важное максимальную глубину стэка;
3 - Тут важно заметить, что верификатор выбрасывает исключение, если обнаруживает незнакомую инструкцию, а интерпретатор просто пропускает их.
4 - вспоминается GNUшный alloca ^^'
Если описать сделанное им кратко, то получается примерно следующее:
- Мы заставляем Flash Player при загрузки специально приготовленного SWF файла попросить слишком много памяти, аллокатор отказывается и возвращает NULL.
- Проверки на NULL не делается, Flash Player пытается записать некоторый DWORD по некоторому адресу (NULL + offset);1
- Мы подбираем offset и DWORD так, чтобы особым образом подкрутить внутренние структуры ABC-верификатора2
- Верификатор особым образом сходит с ума и начинает считать некоторые ранее незнакомые3 ему инструкции - хорошими. Внутри таких инструкций оказывается возможным спрятать от верификатора мешанину из "нехороших" инструкций, манипулирующих со стэком, и (sic!) нативного x86 кода.
- После того как код прошел верификацию он запускается, при этом стэк виртуальной машины размещается на обычном стэке процессора4. Размер у него предвычеслен на этапе компиляции и проверен на этапе верификации. Ну а поскольку верификатор был слегка не в себе, он пропустил байткод, который пишет и читает за пределами стэка виртуальной машины, т.е. прямо из обычного стэка. Далее подмена адреса возврата и дело в шляпе.
Тут важно отметить, что подмена делается аккуратно, shellcode получает подмененный адрес возврата и может завершиться нормально, не вызывая падения Flash Player'а, т.е. незаметно для пользователя.
Вообщем я нахожусь в легком шоке от изящности сей махинации..
--
1 - На эти числа есть ограничения, но подробнее о них вы можете прочитать в самой статье;
2 - ABC - это байткод, который исполняется виртуальной ActionScript машиной. Верификатор проверяет некоторые свойства кода переданного на вход виртуальной машины, например, типы операндов и что самое важное максимальную глубину стэка;
3 - Тут важно заметить, что верификатор выбрасывает исключение, если обнаруживает незнакомую инструкцию, а интерпретатор просто пропускает их.
4 - вспоминается GNUшный alloca ^^'