https://bugtraq.ru/review/archive/2008/13-05-08.html

25-летний баг в BSD; Эти страшные NULL-pointerы; Сотни тысяч IIS пострадали от SQL injection; Microsoft покончила с ботнетом Storm; Microsoft поддерживает "этичных хакеров".

#258, 13.05.2008

25-летний баг в BSD
dl // 12.05.08 17:15
Один из разработчиков OpenBSD обнаружил ошибку в реализации функции seekdir, восходящую по крайней мере к 4.2BSD (август 1983). Выяснилось это во время разбора падений Samba на файловой системе MS-DOS (FAT16?), в процессе которого разработчики Samba признались, что давно используют свою реализацию этой функции под BSD из-за некорректной работы системной. Не вполне понятно, что им помешало рассказать об этом раньше.
Источник: vnode.ch

Эти страшные NULL-pointerы
dl // 05.05.08 22:24
Сначала не удержусь от цитирования компьютерровской статьи об уязвимости в 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. Иметь некое представление о программировании и компьютерной архитектуре иногда полезно даже для авторов компьютерных журналов.
Источник: Компьютерра

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

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

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

Microsoft покончила с ботнетом Storm
dl // 23.04.08 06:15
Согласно заявлению разработчиков MSRT (Malicious Software Removal Tool, ежемесячно обновляющееся средство борьбы с троянами от MS), им удалось очистить столько систем от трояна Storm, лежащего в основе одноименного ботнета, что создатели последнего предположительно отказались от его развития.

За последние 4 месяца 2007 года от Storm было очищено более полумиллиона систем, причем почти половина из них пришлась на сентябрь, первый месяц, когда распознавание Storm было добавлено в MSRT. Первое время создатели Storm пытались бороться с этим - с учетом того, что MSRT обновляется строго раз в месяц, они пытались закидывать свежие версии трояна на зараженные системы непосредственно перед обновлением, чтобы помешать его обнаружению.

Однако сопротивление оказалось бесполезным - по опубликованным в начале месяца оценкам специалистов SecureWorks, Storm откатилась на пятое место среди известных ботнетов с жалкими 85 тысячами подконтрольных систем, 35 тысяч из которых настроены на рассылку спама (и способны рассылать 3 миллиарда писем в день - честно говоря, язык не поворачивается назвать такое положение полным разгромом, хотя удар был нанесен действительно ощутимый).

Впрочем, представитель Microsoft реалистично оценивает ситуацию и считает, что создатели Storm вероятно продолжают зарабатывать на других ботнетах.
Источник: InfoWorld

Microsoft поддерживает "этичных хакеров"
dl // 22.04.08 21:59
Microsoft заявила на днях, что не возражает против анализа уязвимостей своих онлайновых служб сторонними исследователями - пока они не забывают делиться с MS своими открытиями. По словам представителей компании, она придерживается этой политики по крайней мере с прошлого июля и продвигает дополнение к стандарту ISO, которое могло бы защитить подобных "этичных хакеров". Проблема в том, что зачастую такое тестирование сложно отличить от реальных атак, и уже имеются примеры того, как авторы подобных исследований подвергались тем или иным преследованиям после публикации результатов своей работы.
Источник: InfoWorld