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

Эти страшные NULL-pointerы
dl // 05.05.08 22:24
Сначала не удержусь от цитирования компьютерровской статьи об уязвимости в flash-плейере:

"С присущей компьютерам проблемой переполнения буфера памяти мир безопасности вплотную познакомился в 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) [4926]

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

Миллионы домашних роутеров оказались уязвимыми // dl // 22.07.10 10:53
Adobe подлатала Flash // dl // 11.06.10 10:19
Очередные критические уязвимости в Flash и Acrobat // dl // 05.06.10 21:13
Перетягивание флага // dl // 15.02.10 00:39
Adobe выпустил патч для Flash, на подходе Reader // dl // 12.02.10 16:45
Adobe потеряла патч для Flash на 16 месяцев // dl // 09.02.10 20:32
Внеочередной патч IE // dl // 21.01.10 23:27
Массовая атака с помощью pdf-уязвимости // dl // 14.01.10 23:45
Adobe пообещала залатать Акробат через месяц // dl // 16.12.09 22:47
Удаленное замораживание Window 7 и Server 2008 R2 // dl // 12.11.09 16:55

Oracle обновила Java, поломав Eclipse // dl // 29.07.10 20:35
Личная информация сотни миллионов пользователей FaceBook доступна для скачивания // dl // 29.07.10 15:42
Ключи от Интернета // dl // 28.07.10 12:17
В Америке легализовали джейлбрейкинг и взлом DVD // dl // 26.07.10 21:40
LiveJournal заблокировал аутентификацию по OpenID для переименованных аккаунтов // dl // 22.07.10 14:29
Миллионы домашних роутеров оказались уязвимыми // dl // 22.07.10 10:53
Пробуем социализироваться // dl // 21.07.10 20:03
Microsoft выпустила средство для блокировки уязвимых ярлыков // dl // 21.07.10 17:47
Adobe добавит песочницу в Reader // dl // 20.07.10 20:54
Борьба за авторские права оказалась убыточной // dl // 15.07.10 17:42

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