Эти страшные 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)

RuCTF 2008 - итоги
dl // 05.05.08 00:57
Подведены итоги прошедших неделю назад соревнований RuCTF 2008.
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2008/05/01.html]
В продолжавшейся 8 часов игре приняло участие 9 из предварительно заявленных 10 команд, одна - в режиме гостевого участия. Первое место заняла команда HackerDom из УрГУ, второе Smoked Chicken из ЧелГУ и ЮУрГУ, третье - Reboot из УГАТУ. Отрыв первых двух команд выглядит подавляющим, видимо, сказался опыт предыдущих игр в CTF.

Для всех интересующихся организаторы выложили в свободный доступ игровой образ в том виде, в котором его получали команды.

Источник: итоги, образ, ключ для расшифровки+пароли теги: ctf  |  обсудить  |  все отзывы (0)

Раздача Vista SP1 и XP SP3 приостановлена
dl // 30.04.08 00:22
Microsoft приостановила начавшуюся на прошлой неделе автоматическую раздачу Vista SP1 и отложила намеченное на сегодня выкладывание в публичный доступ XP SP3 из-за обнаруженных проблем совместимости в системах с установленной Microsoft Dynamics Retail Management System.
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2008/04/16.html]
Vista SP1 по-прежнему доступна в Windows Update для ручной установки.

Исправления сервис паков находятся в процессе тестирования; предполагается, что в качестве временной заглушки в Windows Update вскоре будет включен фильтр, отсеивающий системы с Microsoft Dynamics RMS.

Источник: cnet теги: microsoft, vista, windows, xp  |  обсудить  |  все отзывы (0)

Microsoft отрицает существование новой уязвимости
dl // 28.04.08 03:17
В блоге Microsoft Security Response Center опубликовано заявление о том, что недавняя массовая атака с использованием sql injection никак не связана с какой-то новой уязвимостью в IIS, SQL server либо в других серверных продуктах MS.
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2008/04/15.html]
Кроме того, эти атаки никак не связаны с выпущенной практически одновременно с сообщениями о первых заражениях рекомендацией по по блокировке возможных последствий уязвимости, допускающей повышение привилегий аутентифицированного пользователя до LocalSystem. Просто так совпало, а полмиллиона зараженных страниц - привет прямым рукам их авторов.

Источник: Microsoft Security Response Center теги: microsoft, iis, server, уязвимости  |  обсудить  |  все отзывы (0)

Сотни тысяч IIS пострадали от SQL injection
dl // 25.04.08 21:01
Согласно информации F-Secure, за последнюю неделю сотни тысяч серверов с установленным IIS пострадали от SQL injection, в результате которого на сайтах появляется код на JavaScript, в свою очередь приводящий пользователей на сайты, пытающиеся подсунуть им трояны.
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2008/04/14.html]
Пока опознано три таких сайта - nmidahena.com, aspder.com и nihaorr1.com, доступ к которым целесообразно заблокировать. Гугль находит более полумиллиона модифицированных таким образом страниц. Пока не вполне понятно, стала ли причиной какая-то новая уязвимость IIS, либо проблема исходит от какого-то стандартного скрипта.

Первая информация об уязвимостях появилась на форумах 17 апреля, на следующий день Microsoft выпустила совет по блокировке атаки с использованием предположительной уязвимости, допускающей повышение привилегий аутентифицированного пользователя до LocalSystem. Среди пострадавших сайтов, кстати, назван aeroflot.ru - что вполне подтверждается. Поиск по зоне .ru вообще дает много любопытных результатов. Под раздачу также попали сайты ООН, американского министерства национальной безопасности и многие другие.

Особенность данного SQL injection в том, что оно передается на сервер в виде вызова функции CAST с параметром в виде куска 16-ричного кода, который она конвертирует в строку, получая на выходе sql-запрос - что делает несколько более сложным его обнаружение и фильтрацию (хотя чтобы эта функция отработала, все равно дело должно дойти до ее исполнения, так что стандартных рекомендаций по фильтрации sql-запросов вполне должно хватить). Далее он пытается внедриться в каждое текстовое поле каждой таблицы - собственно говоря, за счет чего зараженные сайты так удобно искать в гугле - как правило, портится и поле, используемое для формирования заголовка страницы.

Источник: F-Secure теги: iis, microsoft, google, уязвимости, sql injection  |  обсудить  |  все отзывы (3)

««    «   211  |  212  |  213  |  214  |  215  |  216  |  217  |  218  |  219  |  220   »    »»

Предложить свою новость