Начнем со свеженайденного страшного 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, тот запускает отдельную программку с пользовательскими правами. Видимо, в целом картина не сильно успокаивающая и можно найти немало других популярных сервисов, которые можно поймать на эту уловку.

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

В Microsoft все-таки озаботились исправлением части того как бы бага, который обсуждался в конце лета.

Напоминаю суть проблемы. Находим в системе крутящиеся процессы с более высокими правами, чем интерактивный пользователь, которые способны принимать оконные сообщение, и находим там что-нибудь типа поля ввода. Далее заполняем это поле своим кодом, отправив соответствующее сообщение. Но этот код надо еще как-то выполнить, и тут на помощь приходит сообщение WM_TIMER, которое в одном из своих вариантов может приходить с адресом callback-функции. Устанавливаем этот адрес куда-нибудь в район нашего засланного кода и получаем его исполнение с повышенными правами.

Как уже говорилось ранее, в принципе, в системе есть все средства для написания кода, не подверженного этой атаке. Другое дело, что это ж надо еще заставить себя так написать. Видимо, в Microsoft решили не надеяться на сознательность программистов (тем более, что и в родных сервисах, похоже, не все чисто), и решили с этой плюхой побороться. Исправлять всю систему передачи сообщений было бы слишком накладно, а вот работу с WM_TIMER исправили. А заодно от греха поправили и часть системных сервисов.
Источник: Microsoft Security Bulletin

обсудить  |  все отзывы (0)
Выберите оценку 10 (изумительно) 9 (отлично) 8 (хорошо) 7 (неплохо) 6 (средненько) 5 (сойдет) 4 (так себе) 3 (слабо) 2 (плохо) 1 (отвратительно) Вернуться в раздел Перейти к рейтингу Перейти к обсуждению Вернуться к статье	[101602; 34; 7.35]