Сначала не удержусь от цитирования компьютерровской статьи об уязвимости в flash-плейере:
"С присущей компьютерам проблемой переполнения буфера памяти мир безопасности вплотную познакомился в 1996 году [...] В самом простом изложении техническая суть открытия Дауда сводится к очень тонкой работе с NULL pointer, особым указателем адреса памяти с несуществующим значением. [...] Есть возможность заставлять некоторые приложения обращаться к произвольным адресам памяти и выполнять соответствующие коды всякий раз, когда происходит доступ к NULL pointer. [...] Если эти самые NULL-указатели так опасны, почему их до сих пор используют в кодах программ, вместо того чтобы от них отказаться? К сожалению, эта проблема программирования имеет слишком глубокие корни, уходящие к аппаратным кодам, которые непосредственно управляют работой регистров памяти."
Звучит сенсационно - вроде как волшебным образом ноль превращается в произвольное число. Не очень понятно, правда, с чего это вдруг программа полезла к нулевому указателю, а операционная система ее туда пустила. Попробуем разобраться.
Что происходит на самом деле. Происходит, во-первых, хорошо известное целочисленное переполнение (большим unsigned int соответствуют отрицательные signed int, чем можно играть при смешивании unsigned/signed операций). Полученное извне большое беззнаковое число SceneCount проскакивает через знаковую проверку jg, после чего поступает на вход функции выделения памяти, которая, не будучи в состоянии выделить отрицательное количество байтов, возвращает тот самый NULL (имеющий в данном случае вполне существующее значение 0).
Во-вторых, происходит отсутствие проверки возвращаемого значения функции выделения памяти, что приводит к тому, что полученный NULL уходит в дальнейшую обработку. Далее к нему прибавляется все то же SceneCount, умноженный на 12 (размер структуры), и полученный адрес, отсчитываемый от нуля, используется для записи информации. Соответственно, манипулируя значением SceneCount, которое берется из заголовка swf-файла, атакующий может заставить плейер записать почти произвольную информацию в почти произвольную область памяти процесса. Что, впрочем, еще полдела, поскольку дальше остается разобраться с этими "почти", ну да это уже другой вопрос, которому, к слову, посвящено более половины исходного документа.
Переводя на русский язык:
1. Обращение к произвольным адресам памяти при доступе к NULL pointer не имеет ни малейшего отношения к действительности, равно как и "аппаратные коды, управляющие работой регистров памяти". Надумана и опасность нулевых указателей - их для того и придумали, чтобы облегчить проверки, которыми в данном случае пренебрегли. Проблема не в обращении к нулевому указателю (которое отловит любая современная ОС), а в использовании непроверенного значения в качестве базы для операций с указателями.
2. Описываемая уязвимость в принципе не имеет отношения к переполнению буфера. Да и к новому классу ее можно отнести с большой натяжкой.
3. Ну и до кучи - с "присущей компьютерам проблемой переполнения буфера памяти мир безопасности вплотную познакомился" вовсе не в 1996 году, а существенно раньше. Срыв стека широко использовался еще в вирусе Морриса, а известен был задолго до того.
4. Некое представление о программировании иногда полезно даже для авторов компьютерных журналов.
