> Начнем со свеженайденного страшного Windows-бага,
> против которого вроде как нет противоядия. Вкратце о сути
> идеи. Как известно, в Windows любая программа может послать
> любому окну любое сообщение, при этом источник сообщения
> определить невозможно.
> Не любая любому, это только если они на одном десктопе. А
> десктоп – защищаемый об'єкт – право посылать сообщение
> окнам на нём нужно ещё иметь.
Да, это понятно, я решил не усложнять, потому как обычно все все равно в рамках одного десктопа происходит. А вот в момент описания борьбы - да, согласен, пропустил (да и не программировал я их сам ручками, только описание давно смотрел, а сейчас поленился проштудировать, каюсь).
> Так было заведено давным давно, и даже не с NT 3.5
> (3.1 на самом деле), как пишет автор сообщения, а со
> старого доброго 16-битного Windows - потому как смена этого
> механизма привела бы к не самым большим, но все же
> проблемам по переносу старого 16-битного софта под
> Win32
> Мало того, это было бы непрактично и неправильно – делать
> иначе. Почему бы ни дать приложениям, запущенным на одном
> десктопе, взаимодействовать между собой, используя хоть и
> не защищённый, но, за счёт этого, эффективный механизм?
умгум
> (если кто не помнит, для перехода индустрии под
> Win32 потребовался выход Windows'95, до тех же пор многие
> производители софта особо и не утруждали себя этим
> переносом).
> Итак, схема взлома. Находим подходящий сервис,
> исполняющийся из-под системного аккаунта и способный
> открывать интерактивные окна.
>
> Не совсем корректно. Что такое интерактивные окна? – те,
> которые видно? Ну так это вовсе не обязательно, можно и
> скрытому слать. Точнее сказать "находим поток,
> обрабатывающий оконные сообщения нашего десктопа, и
> запущенный в процессе, с правами системы". Как частный,
> более простой для поиска, случай, достаточно найти окно на
> нашем десктопе, созданное процессом с системным акаунтом. В
> подавляющем большинстве случаев (возможно всегда, хотя
> очень сомневаюсь) это будет окно какого-то интерактивного
> сервиса.
Под интерактивными понимались те, которым можно послать сообщения.
> Находим в окне, которое открыл сервис, подходящий
> элемент управления (edit box) и вставляем туда побольше
> символов, включающих в том числе внедряемый код (между
> делом для этого, возможно, придется снять ограничение на
> количество символов, которые можно вставить в текстовое
> поле, но и это можно сделать, послав сообщение, так что это
> непринципиально). В итоге все это хозяйство оказывается
> где-то в недрах адресного пространства данного приложения.
> Где именно - можно определить экспериментальным путем,
> вставив в текст некую сигнатуру и найдя ее с помощью
> отладчика. Далее внедренный код надо бы как-то выполнить.
> На помощь приходит еще одно сообщение, WM_TIMER, в качестве
> одного из параметров которого можно указать адрес
> callback-функции. Стало быть, посылаем WM_TIMER, передав
> адрес, находящийся внутри блока наших засланных команд,
> после чего наш засланный код выполняется с системными
> правами.
>
> Не обязательно с системными правами. Поток, в контексте
> которого будет выполнен код (это тот поток, который и
> обработал WM_TIMER, он же и создал окно), может
> использовать другие, нежели процесс, права. Например,
> используя механизм перевоплощения он может ограничить свои
> права до прав пользователя, на десктопе которого и созданы
> эти окна.
Ну это уже частности, а текст все-таки популярный. Рассматривается худший случай.
> Из вышесказанного делается вывод о наличии
> принципиальной уязвимости системы передачи сообщений
> Windows и затягивается очередная песня про мастдай, потому
> как MSовцы ничего в ней не хотят менять.
>
> Овцы сделали всё правильно. Десктоп и рабочая станция –
> защищаемые об'єкты. Чего ещё нужно для полного счастья?
Чтоб их начали использовать :)
> Сразу скажу свое мнение о данной уязвимости. Схема
> хороша и заслуживает занесения в список проверяемых
> потенциальных уязвимостей отдельных сервисов, но говорить о
> жуткой неизлечимой дырке рановато. Конечно, наличие
> идентификатора источника сообщения могло бы пригодиться при
> программировании, но и в этом случае его анализ требовал бы
> усилий со стороны программиста. Полный запрет приема
> сообщений от сторонних процессов, пожалуй, нереален.
> Добавление такой возможности в список прав - ну, возможно,
> и помогло бы, но ведь существуют всякие автоматизаторы,
> частенько исполняющиеся с системными правами, так что при
> желании лазейку можно было бы и найти. Кроме того, не
> забудем о необходимости перетряхивания всего существующего
> софта, потому как просто так добавить опциональный параметр
> в оконную функцию вряд ли удастся.
>
> Как я уже писал, параметр уже есть – можно запретить
> создание интерактивными сервисами окон на видимых десктопах
> вообще. Но зачем? Чтобы программисты третьих вендоров не
> писали уязвимый софт? Тогда и NULL в качестве
> lpSecurityAttributes при создании чего-либо (в том числе и
> файлов) нужно запретить передавать – чтобы каждый ещё раз
> задумался о безопасности. Кому это нужно?
> Кроме того, разрешая посылать сообщения другим, возможно и
> не подозревающим об этом приложениям, Win32 приобретает
> большую гибкость, большую функциональность.
Ну, если прикинуть, такая функциональность нужна на самом деле очень небольшому классу программ - типа дающих работать с макросами. Nag screenы гасить удобно, опять же :)
> Однако ж посмотрим, какие средства у нас есть на
> руках, чтобы бороться с данной проблемой. Во-первых, писать
> такие сервисы, открывающие интерактивные окна - в принципе
> моветон, за который надо бить ногами, потому как есть
> стандартная схема, обеспечивающая взаимодействие сервиса с
> пользователем - написание вспомогательной программки,
> запускающейся с пользовательскими правами и тем или иным
> способом взаимодействующей с сервисом (хотя, в принципе,
> тут можно попробовать найти лазейку и встроиться в это
> взаимодействие).
>
> Есть разница. Это «другое» взаимодействие неизбежно должно
> осуществляться с помощью защищаемых об'єктов. Поскольку нет
> иных разделяемых и не защищаемых, кроме GUI'шных, об'єктов,
> пригодных для взаимодействия через них (по крайней мере, я
> не знаю, и, кажется, так было где-то написано).
Это если разработчик не влепил NULL В LPSECURITY_ATTRIBUTES :) А еще делают взаимодействие просто через файлы или реестр. Опять та же картина - возможность прикрыть дырку есть, но фиг кто ей пользуется.
> Далее, не совсем верно утверждение, что 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.".
>
> Попадать в очередь сообщений и в оконную процедуру – не
> одно и тоже. Из того, что сообщение можно отфильтровать в
> оконной процедуре, вовсе не следует, что его можно
> отфильтровать. В MSDN не написано, но DispatchMessage
> вызывает TimerProc даже если hWnd = NULL. Так что если уж
> отфильтровывать, то в цикле сообщений, а не в оконной
> процедуре.
Я, в общем, это и предполагал, но на всякий случай не уточнил, куда именно эту обработку втыкать :)
> Желающие могут проверить - без какого-никакого
> цикла обработки сообщений никакой callback от таймера
> работать не будет, а стало быть, вставить свою обработку
> таки можно. Другой вопрос, кто этим озаботился :) Наконец,
> особые параноики наподобие авторов PGP, вообще не
> используют стандартные классы окон и до кучи используют
> дополнительный драйвер, защищающий память приложения.
>
>
> Авторы PGP больше для меня не параноики:). PGP 7.1.1
> (corporate desktop) включает интерактивный сервис :). Вот
> от них не ожидал. Так что PGP не только обеспечивает
> секретность и аутентичность вашей переписки, но и позволяет
> вам получить достойные права на локальной машине! :)
:)
> Таким образом, из общесистемной проблема все-таки
> переходит в разряд проблем авторов сервисов, на которых и
> надо перевести стрелки - в конце концов, и в проблеме
> постоянно вылезающих buffer overflow можно обвинять
> создателей C, но это нефункционально :) Вот если б в
> примере оказался какой-нибудь стандартный сервис, это было
> бы гораздо интереснее.
>
> В стадии разработки :) Был человек, у которого "планировщик
> 2К" согрешил. Мне не удалось в ХР найти, но я не очень и
> искал.
>
> Однако ж ситуация вовсе не безоблачна. Написав
> этот абзац, полез смотреть, что творится у меня под носом -
> увы, сходу нашлась пара примеров, Outpost и MDaemon,
> которые ведут себя так же. К чести Norton Antivirus, тот
> запускает отдельную программку с пользовательскими правами.
>
>
> А вот NU2002 – не запускает. А может и запускает – это не
> показатель см. мою прогу в программинг (она, правда, тоже
> не всех грешников показывает, но лучше чем просто смотреть
> на тип сервиса вручную, или на заголовки окон).
>
> Думаю, что можно найти немало других популярных
> сервисов, которые можно поймать на эту уловку.
>
> Я уже думаю, что трудно найти такие, которых нельзя поймать
> :)
Вообще же действительно получился новый класс атак типа buffer overflow - вроде и не ОС виновата, но отлавливать такое в разных сервисах будут еще очень долго.
Ну а за замечания спасибо, в релизе учту :)
|
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
