Not a kernel guy

… in the Windows kernel team

Tuesday, April 15, 2008

Анализ одной уязвимости в Flash.

Томас Пташек (Thomas Ptacek) анализирует нечеловеческий эксплоит Марка Доуда (Mark Dowd), использующий уязвимость в Flash.

Эксплоит использует целочисленное переполнение, возникающее из-за того, что Flash runtime использует знаковое число, прочитанное из SWF файла, как беззнаковый размер выделяемого блока памяти. В итоге Flash пытается выделить несколько гигабайт памяти, получает в ответ NULL, но не проверяет его, а пишет 32-х разрядное число по смещению от полученного нулевого указателя. Марк вычислил, что если смещение X превышает 0×80000000 и при этом X+4 делится без остатка на 12, то результирующий адрес получается валидным. Записываемое 32-х битное значение получается из исходного 16-ти разрядного числа вычитанием значения еще одной переменной. Иными словами, ни указатель, ни записываемое значение не контролируются хакером полностью.

Тем не менее…

Flash использует ActionScript, который является ни чем иным как версией JavaScript, скомпилированный в байт код. Подменяя байт код, хакер может получить доступ к любому участку памяти в процессе. Проблема только в том, что Flash runtime проверят байт код на корректность перед выполнением и хакер не может модифицировать байт код просто так.

Тем не менее…

Для повышения производительности Flash runtime использует два немного отличающихся набора проверок. Первый используется при загрузке кода, а второй во время выполнения программы. Запись 32-х разрядного числа по смещению от нулевого указателя может изменить таблицу длин байт-кодов, что делает некоторые байт-коды длиннее, вводя в заблуждение загрузчик кода. В тоже время интерпретатор выполняет все инструкции, в том числе и те, что спрятаны хакером внутри ставшими вдруг длинными (с точки зрения загрузчика) байт-кодов! Если бы только не одна сложность. Код, добавленный хакером, не должен менять поведение оригинального кода, иначе это будет не троянский конь, а слон в посудной лавке.

Тем не менее…

Экплоит Марка не нарушает функциональность существующих байт-кодов; внедряемый трояном код восстанавливает измененные при внедрении кода значения в стеке; и к тому же для успешного внедрения используется комбинация байт кодов и x86 инструкций.

Кроме того, этот эксплоит работает под IE и Firefox, не смотря на разные версии Flash, которые использую эти браузеры. И наконец, он работает и на Vista, так как Flash не использует ASLR.

PS: Охренеть, простите за мой французский.

Posted at 10:08 pm •

RSS feed | Trackback URI

15 Comments »

[...] from blog.not-a-kernel-guy.com. Published Wednesday, April 16, 2008 7:09 AM by alexeypa Filed under: Flash, [...]

 
Comment by Denis Klykvin — April 15, 2008 @ 11:58 pm

Маньяяяяк…
А если не секрет, кем ты работаешь?

Comment by Not a kernel guy — April 16, 2008 @ 9:51 am
 
 
Comment by alick — April 16, 2008 @ 12:31 am

Это ж какой мозг надо иметь, чтоб такое раскопать.

 
Comment by 468 — April 17, 2008 @ 6:05 am

Да уж… охренеть (С) :) Прочитаю ка я еще пару раз заново…

 
Comment by 468 — April 17, 2008 @ 6:13 am

Вопрос :)

В самом начала должна была выделиться память, чтобы записать по PVOID+N что то.
Память ведь не выделяется (возвращается NULL) и таким образом мы записываем “что то” в произвольное место производное од PVOID+N

вопрос - изначально память вообще не выделилась - и это все равно не грохает флеш?

Если я правильно понял… Читать оригинал на аглийском мне пока рано, на русском то сложно понять)

 
Comment by 468 — April 17, 2008 @ 6:16 am

если я правильно понял получается что память не выделилась, ошибка выделения обрабатывается некорректно, но все остальное не вешается и все работает корректно - тоесть у нас не “слон в посудной лавке” (срабатывает ексепшн хендлинг дальше и память всетаки выделяется с размером по умолчанию??) … вот..

PS очень прикольная головоломка :)

Comment by Not a kernel guy — April 17, 2008 @ 6:56 pm

Я не знаю как там используется указатель на выделенный блок. Получается что напрямую не используется.

 
 
Comment by Konstantin — April 17, 2008 @ 8:11 am

Как я понимаю с аппаратным DEP’ом бояться нечего. Я правильно понимаю? ;)

Comment by Not a kernel guy — April 17, 2008 @ 6:58 pm

Не факт. DEP контролирует исполнения native кода, не более того. А от внедрения байт-кодов в программу для интерпретатора он никак не спасёт.

 
 
Comment by Sergey Rudenko — April 18, 2008 @ 4:00 am

За французский прощаем.
Интересный пост, на досуге перечитаю в оригинале.

 
Comment by Konstantin — April 19, 2008 @ 6:59 pm

Как я понял из статьи внедрение байт-кодов используется чтобы получить полный доступ к стеку. При отключенном DEP-е это значит что в стек можно записать произвольный код и выполнить его. А вот какая от этого польза при включенном DEP-е? Максимум что тут можно - это уронить браузер.

Comment by Not a kernel guy — April 19, 2008 @ 9:20 pm

А вот какая от этого польза при включенном DEP-е?

При включенном DEP-е можно исполнять вредоносный байт код. Насколько сильно так можно напакостить - это отдельный вопрос. Может там найдется страница с правами на выполнение кода и запись. :-)

 
 
Comment by 1ife — April 20, 2008 @ 3:26 am

Спасиб..интересно…пригодится….

 
Pingback by Алёна C++: 3D во флеше — April 20, 2008 @ 10:26 am

[...] Томас Пташек ее кратко перессказывает. А вот здесь: Анализ одной уязвимости в Flash Пташека по-русски перессказывает Not a kernel [...]

 

Your Comment (smaller | larger)

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Powered by WordPress