BugTraq.Ru: Эти страшные NULL-pointerы

"С присущей компьютерам проблемой переполнения буфера памяти мир безопасности вплотную познакомился в 1996 году [...] В самом простом изложении техническая суть открытия Дауда сводится к очень тонкой работе с NULL pointer, особым указателем адреса памяти с несуществующим значением.
[Не забывайте при копировании материала указывать полный адрес источника: http://bugtraq.ru/rsn/archive/2008/05/02.html]
[...] Есть возможность заставлять некоторые приложения обращаться к произвольным адресам памяти и выполнять соответствующие коды всякий раз, когда происходит доступ к NULL pointer. [...] Если эти самые NULL-указатели так опасны, почему их до сих пор используют в кодах программ, вместо того чтобы от них отказаться? К сожалению, эта проблема программирования имеет слишком глубокие корни, уходящие к аппаратным кодам, которые непосредственно управляют работой регистров памяти."

Звучит сенсационно - вроде как волшебным образом ноль превращается в произвольное число. Не очень понятно, правда, с чего это вдруг программа полезла к нулевому указателю, а операционная система ее туда пустила (обычно подобное обращение вызывает аппаратное исключение). Попробуем разобраться.

Что происходит на самом деле. Происходит, во-первых, хорошо известное целочисленное переполнение (большим unsigned int соответствуют отрицательные signed int, чем можно играть при смешивании unsigned/signed операций). Полученное извне большое беззнаковое число SceneCount проскакивает через знаковую проверку jg, после чего поступает на вход функции выделения памяти, которая, не будучи в состоянии выделить отрицательное количество байтов, возвращает тот самый NULL (имеющий в данном случае вполне существующее значение 0).

Во-вторых, происходит отсутствие проверки возвращаемого значения функции выделения памяти, что приводит к тому, что полученный NULL уходит в дальнейшую обработку. Далее к нему прибавляется все то же SceneCount, умноженный на 12 (размер структуры), и полученный адрес, отсчитываемый от нуля, используется для записи информации (т.е. нет никакого обращения к нулевому указателю, а есть обращение к адресу, некорректно сформированному из-за отсутствия проверки). Соответственно, манипулируя значением SceneCount, которое берется из заголовка swf-файла, атакующий может заставить плейер записать почти произвольную информацию в почти произвольную область памяти процесса. Что, впрочем, еще полдела, поскольку дальше остается разобраться с этими "почти", ну да это уже другой вопрос, которому, к слову, посвящено более половины исходного документа.

1. Обращение к произвольным адресам памяти при доступе к NULL pointer не имеет ни малейшего отношения к действительности, равно как и "аппаратные коды, управляющие работой регистров памяти", никак не связаны с NULL ("регистры памяти" звучат очень красиво, но не имеют ни малейшего отношения к указателям, вся фраза - пускание пыли в глаза неспециалистам).

2. Сильно преувеличена опасность нулевых указателей - их для того и придумали, чтобы сделать возможными проверки, которыми в данном случае пренебрегли. Проблема не в обращении к нулевому указателю (которое отловит любая современная ОС), а в использовании непроверенного значения в качестве базы для операций с указателями.

3. Описываемая уязвимость в принципе не имеет отношения к переполнению буфера. Да и к новому классу ее можно отнести с большой натяжкой.

4. Ну и до кучи - с "присущей компьютерам проблемой переполнения буфера памяти мир безопасности вплотную познакомился" вовсе не в 1996 году, а существенно раньше. Срыв стека широко использовался еще в вирусе Морриса, а известен был задолго до того.

5. Иметь некое представление о программировании и компьютерной архитектуре иногда полезно даже для авторов компьютерных журналов.

Источник: Компьютерра

теги: flash, .net, уязвимости | предложить новость | обсудить | все отзывы (2)

[6076]

назад « » вперед

аналогичные материалы

Взлом 180 тысяч ASP.Net сайтов через sql-инъекции // 21.10.11 00:22
Adobe опять придется чинить подсматривающие камеры на Маках // 21.10.11 00:03
Второй срочный патч Flash за 9 дней // 16.06.11 02:42
Внеочередное обновление Flash // 07.06.11 23:32
Adobe признала существование свежей уязвимости в Flash и Reader, готовит срочный патч - через недельку // 15.03.11 01:31
Adobe подлатала Flash // 21.09.10 02:09
Еще один повод поставить FlashBlock // 14.09.10 18:16

последние новости

Уязвимость камер TRENDnet открыла свободный доступ к домашнему видео // 08.02.12 00:36
Взломщики опубликовали код pcAnywhere // 07.02.12 21:37
Интеграционное // 07.02.12 17:27
Adobe добавит песочницу в Flash для Firefox // 07.02.12 14:44
Google все-таки стал проверять приложения из Маркета // 03.02.12 19:50
Symantec обнаружила полиморфного андроидного трояна из России // 03.02.12 19:36
8 марта у жертв DNSChanger закончится интернет // 03.02.12 12:01

Комментарии: