BugTraq.Ru
Русский BugTraq
https://bugtraq.ru/rsn/archive/2008/05/02.html

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

"С присущей компьютерам проблемой переполнения буфера памяти мир безопасности вплотную познакомился в 1996 году [...] В самом простом изложении техническая суть открытия Дауда сводится к очень тонкой работе с NULL pointer, особым указателем адреса памяти с несуществующим значением.
[Не забывайте при копировании материала указывать полный адрес источника: //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) [11022]
назад «  » вперед

аналогичные материалы
Три миллиона электронных замков готовы открыть свои двери // 22.03.24 20:22
Четверть приложений, использующих Log4j, до сих пор уязвима // 11.12.23 18:29
Атака в стиле Meltdown на iOS/macOS-браузеры // 25.10.23 22:40
Массовое внедрение вредоносного кода в драйверы Windows // 17.07.23 01:42
Переполнение буфера остается самой опасной уязвимостью // 30.06.23 23:32
Уязвимость в KeePass // 21.05.23 19:20
Рекордное число уязвимостей в 2021 // 28.05.22 21:06
 
последние новости
Три миллиона электронных замков готовы открыть свои двери // 22.03.24 20:22
Doom на газонокосилках // 28.02.24 17:19
Умер Никлаус Вирт // 04.01.24 14:05
С наступающим // 31.12.23 23:59
Четверть приложений, использующих Log4j, до сих пор уязвима // 11.12.23 18:29
Google Drive находит файлы // 07.12.23 01:46
Google Drive теряет файлы // 27.11.23 20:02

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

да блин! зачем оно редиректит на главную после 20 секунд... 06.05.08 09:44  
Автор: gorbunkul Статус: Незарегистрированный пользователь
<"чистая" ссылка>
да блин! зачем оно редиректит на главную после 20 секунд чтения?! ёмаё!
иногда такая реакция случается на слишком агрессивные персональные файрволлы 06.05.08 15:05  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Хотя в статьях она унаследована от форума, надо будет ослабить проверку, в них она не так критична.
<добавить комментарий>





  Copyright © 2001-2024 Dmitry Leonov Design: Vadim Derkach