Показано с 1 по 2 из 2.

Эти страшные NULL-pointerы

  1. #1
    Senior Member Репутация Репутация Репутация Репутация Репутация Репутация Репутация Репутация Репутация Репутация Репутация Аватар для SDA
    Регистрация
    07.01.2005
    Адрес
    Москва
    Сообщений
    7,168
    Вес репутации
    3166

    Эти страшные NULL-pointerы

    BugTraq: Обозрение #258
    Сначала не удержусь от цитирования компьютерровской статьи об уязвимости в 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 не имеет ни малейшего отношения к действительности, равно как и "аппаратные коды, управляющие работой регистров памяти", никак не связаны с NULL ("регистры памяти" звучат очень красиво, но не имеют ни малейшего отношения к указателям, вся фраза - пускание пыли в глаза неспециалистам).

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

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

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

    5. Иметь некое представление о программировании и компьютерной архитектуре иногда полезно даже для авторов компьютерных журналов.
    Источник: Компьютерра http://www.computerra.ru/think/kiwi/356355/

  2. Будь в курсе!
    Реклама на VirusInfo

    Надоело быть жертвой? Стань профи по информационной безопасности, получай самую свежую информацию об угрозах и средствах защиты от ведущего российского аналитического центра Anti-Malware.ru:

    Anti-Malware Telegram
     

  3. #2
    Senior Member Репутация Репутация Репутация Репутация Репутация Репутация Репутация Репутация Репутация Репутация Репутация Аватар для maXmo
    Регистрация
    21.09.2004
    Сообщений
    1,411
    Вес репутации
    292
    Цитата Сообщение от SDA Посмотреть сообщение
    Происходит, во-первых, хорошо известное целочисленное переполнение (большим unsigned int соответствуют отрицательные signed int, чем можно играть при смешивании unsigned/signed операций). Полученное извне большое беззнаковое число SceneCount проскакивает через знаковую проверку jg
    почему это для беззнакового числа знаковая проверка? И как оно может через него проскочить, ведь именно знаковая проверка воспринимает большое беззнаковое как отрицательное знаковое? Что-то они там ещё недоговаривают.

Похожие темы

  1. windows не удалось найти '(null)'
    От пипетка в разделе Помогите!
    Ответов: 11
    Последнее сообщение: 09.06.2011, 23:45
  2. Страшные тормоза
    От Forgotten в разделе Помогите!
    Ответов: 11
    Последнее сообщение: 20.12.2010, 19:33
  3. Страшные вирусы
    От B_l_a_c_k_(m.s) в разделе Помогите!
    Ответов: 13
    Последнее сообщение: 03.08.2009, 12:11
  4. Проблема с http:///null.exe
    От mohandas в разделе Помогите!
    Ответов: 1
    Последнее сообщение: 25.03.2009, 18:05
  5. Страшные глюки системы, или вирус??
    От LAM в разделе Помогите!
    Ответов: 7
    Последнее сообщение: 17.03.2007, 18:22

Свернуть/Развернуть Ваши права в разделе

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •  
Page generated in 0.00885 seconds with 16 queries