Отправляет email-рассылки с помощью сервиса Sendsay

BugTraq: Обозрение

Подписаться Бесплатная «Серебряная» новостная рассылка Подписчиков 13.827 RSS
←   Август 2002   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


За последние 60 дней ни разу не выходила


Сайт рассылки: http://www.bugtraq.ru/review/
Открыта: Давно

Автор
Дмитрий Леонов

Статистика

13.827 подписчиков
0 за неделю
←   Все выпуски   →

страшная дырка в Windows; Flash; дела книжные; long live PGP; DEF CON X; Phrack 59


Информационный Канал Subscribe.Ru
BugTraq.Ru


Рассылки Subscribe.Ru
BuqTraq: Обозрение
BuqTraq: Russian Security Newsline
BuqTraq: Бред сивой кобылы
BugTraq: Закон есть закон
ЕжеПравда
Новости из мира распределенных систем

#122, 31.08.02

Начинаем подводить летние итоги. Точнее, то, что осталось в памяти.

Начнем со свеженайденного страшного Windows-бага, против которого вроде как нет противоядия. Вкратце о сути идеи. Как известно, в Windows любая программа может послать любому окну любое сообщение (на самом деле, с некоторыми оговорками, о которых позже), при этом источник сообщения определить невозможно. Так было заведено давным давно, и даже не с NT 3.5 (3.1 на самом деле), как пишет автор сообщения, а со старого доброго 16-битного Windows - потому как смена этого механизма привела бы к не самым большим, но все же проблемам по переносу старого 16-битного софта под Win32 (если кто не помнит, для перехода индустрии под Win32 потребовался выход Windows'95, до тех же пор многие производители софта особо и не утруждали себя этим переносом).

Итак, схема взлома. Находим подходящий сервис, исполняющийся из-под аккаунта, с бОльшими правами, чем наш текущий, который будет способен принимать оконные сообщения, что мы ему собираемся посылать (грубо говоря, способный открывать окна :). Находим в окне, открытом сервисом, подходящий элемент управления (edit box) и вставляем туда побольше символов, включающих в том числе внедряемый код (между делом для этого, возможно, придется снять ограничение на количество символов, которые можно вставить в текстовое поле, но и это можно сделать, послав сообщение, так что это непринципиально). В итоге все это хозяйство оказывается где-то в недрах адресного пространства данного приложения. Где именно - можно определить экспериментальным путем, вставив в текст некую сигнатуру и найдя ее с помощью отладчика. Далее внедренный код надо бы как-то выполнить. На помощь приходит еще одно сообщение, WM_TIMER, в качестве одного из параметров которого можно указать адрес callback-функции. Стало быть, посылаем WM_TIMER, передав адрес, находящийся внутри блока наших засланных команд, после чего наш засланный код выполняется с правами того аккаунта, из-под которого был запущен сервис, если повезет - с системными. Из вышесказанного делается вывод о наличии принципиальной уязвимости системы передачи сообщений Windows и затягивается очередная песня про мастдай, потому как MSовцы ничего в ней не хотят менять.

Сразу скажу свое мнение о данной уязвимости. Схема хороша и заслуживает занесения в список проверяемых потенциальных уязвимостей отдельных сервисов (по сути это действительно новый класс уязвимостей, аналогичный buffer overflow), но говорить о жуткой принципиально неизлечимой дырке рановато. Полный запрет приема сообщений от всех сторонних процессов, пожалуй, не имеет смысла и потому нереален. Конечно, наличие идентификатора источника сообщения могло бы пригодиться при программировании, но и в этом случае его анализ требовал бы усилий со стороны программиста. К тому же, добавление к сообщению информации об источнике приведет к необходимости перетряхнуть весь существующий софт, потому как просто так добавить опциональный параметр в оконную функцию вряд ли удастся. Наконец, подобная радикальная смена существующего API просто не нужна, поскольку начиная с NT 3.51 существует вполне рабочий механизм Window Stations и Desktops, созданный, по утверждению MSDN, в первую очередь именно для разработчиков интерактивных сервисов и обладающий всеми средствами по разграничению доступа.

Итак, какие средства у нас есть на руках, чтобы бороться с данной проблемой. Во-первых, рабочие станции и десктопы, у которых с защитой все в порядке - сервис, к примеру, вполне в состоянии создать окно, которое будет выполняться в контексте текущего пользователя. Во-вторых, даже если забыть о десктопах, есть вполне стандартная схема, обеспечивающая взаимодействие сервиса с пользователем - написание вспомогательной программки, запускающейся с пользовательскими правами и тем или иным способом взаимодействующей с сервисом (по уму - с помощью защищенных объектов ядра). Далее, не совсем верно утверждение, что WM_TIMER не попадает в очередь сообщений и его нет возможности игнорировать - цитируя MSDN, "You can process the message by providing a WM_TIMER case in the window procedure. Otherwise, the default window procedure will call the TimerProc callback function specified in the call to the SetTimer function used to install the timer.". Желающие могут проверить - без какого-никакого цикла обработки сообщений никакой callback от таймера работать не будет, а стало быть, вставить свою обработку таки можно. Другой вопрос, кто этим озаботился - тем более что в оконную функцию сообщение все же не попадет, и проверку придется встраивать непосредственно в цикл обработки сообщений. Наконец, особые параноики наподобие авторов PGP, вообще не используют стандартные классы окон и до кучи используют дополнительный драйвер, защищающий память приложения.

Таким образом, из общесистемной проблема все-таки переходит в разряд проблем авторов сервисов, на которых и надо перевести стрелки - в конце концов, и в проблеме постоянно вылезающих buffer overflow можно обвинять создателей C, но это нефункционально :) Вот если б в примере оказался какой-нибудь стандартный сервис, это было бы гораздо интереснее. Однако ж ситуация вовсе не безоблачна. Написав этот абзац, полез смотреть, что творится у меня под носом - увы, сходу нашлась пара примеров, Outpost и MDaemon, которые, похоже, ведут себя так же. К чести Norton Antivirus, тот запускает отдельную программку с пользовательскими правами. Видимо, в целом картина не сильно успокаивающая и можно найти немало других популярных сервисов, которые можно поймать на эту уловку.

Отдельное спасибо Бяше за замечания к первому варианту этого текста. Заинтересовавшимся темой также имеет смысл ознакомиться с этой веткой форума.

А вот дырка, которую eEye Digital Security, съевшая свору собак на поиске всевозможных buffer overflow, нашла в Flash Player, мне представляется гораздо более опасной. Дано достаточно подробное описание проблемы, и не думаю, что понадобится много временя для появления в широких массах готового эксплоита. А учитывая, что у большинства пользователей стоит вовсе не последняя исправленная версия Flash Player, и оочень вряд ли все они побежали его обновлять, можно с легкостью предсказать, что первый же червяк, использующий эту уязвимость, вызовет неслабую эпидемию.

Вообще, я боюсь, что Flash еще предстоит очень сильно рвануть, и тогда никому мало не покажется. Потихоньку выросший из средства для рисования мультиков в полноценную систему программирования и тихой сапой занявший ту нишу, которая на вебе планировалась для Java, Flash не мог не столкнуться с болезнями роста, которые случаются с системами, значительно переросшими свою начальную концепцию. Не забудьте, в отчете eEye упоминается еще "около 17" потенциально уязвимых моментов, работа над которыми продолжается, и многие ранее обнаруженние уязвимости типа падения броузера при получении флеш-ролика с битыми заголовками - похоже, ребята просто не рассматривали ситуацию, когда ролик создается нестандартными средствами.

Немного о книгах. Мои поздравления Алексею Лукацкому, чья книга "Protect Your Information With Intrusion Detection" выходит в ноябре. Выход "нашей" книги "там" - не самое частое событие.

Еще одна новинка - свежевышедшая книга Виктора Наумова Право и Интернет: очерки теории и практики, подводящая некоторый итог исследованиям автора, работы которого по юридическим проблемам интернета (в первую очередь российского) хорошо известны. Немалая часть книги посвящена примерам конкретных судебных разбирательств.

Потихоньку загибающаяся в недрах NAI после ухода Циммермана PGP, похоже, обретает новую жизнь. Для дальнейшей поддержки продукта организована новая компания PGP corporation, которая уже анонсировала выход в четвертом квартале этого года PGP 8.0.

В августе случился очередной, десятый DEF CON. Ничего особо сенсационного не случилось, вовсю обсуждались вопросы любимого DMCA, копирайтов и борьбы с ними, обсуждались грядущие черви, был продемонстрирован троян, использующий для прикрытия скрытое окно IE.

В июле вышел очередной 59-й Phrack. Из любопытного - статья по методологии построения операционных систем, работа с таблицей прерываний под Linux, внедрение кода в процессы на лету, манипулирование объектами ядра Windows 2000 и т.п.

О печальном. 6 августа умер Эдсгер Дейкстра. Людям, понимающим под программированием нечто большее чем раскидывание кнопок по формам, он, скорее всего знаком как один из основоположников структурного программирования (которое, к слову, не стоит путать с крестовым походом против многострадального оператора goto) и как человек, заложивший основы для превращения программирования в науку.

Из локальных новостей. Продолжает обрастать новыми возможностями форум. Началась и продолжается публикация перевода книги Underground. В течение первой недели сентября (чтоб веселее было приступать к работе/учебе) случится массовая публикация большинства оставшихся глав, готовится к выкладыванию и приличная порция новых статей. Подписчики RSN узнают об этом первыми :)

И о RC5. HZTeam, оставаясь безусловным лидером по всем показателям среди русскоязычных команд, все чаще взбирается на первую строчку и в общем зачете. В течение всего лета продолжалась борьба между странами. Игра в чехарду между России с Германией продолжается уже больше года, в начале лета мы успели обогнать Голландию и вроде бы уйти в отрыв, но сейчас ситуация вновь накалилась, так что если вы до сих пор не указали в своих настройках страну, сейчас самое время этим озаботиться.



Ведущий рассылки - Дмитрий Леонов
http://www.bugtraq.ru

http://subscribe.ru/
E-mail: ask@subscribe.ru 		Отписаться
Убрать рекламу
В избранное