информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяSpanning Tree Protocol: недокументированное применениеАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft закрыла серьёзную уязвимость,... 
 Прощаемся с Windows 7 
 С наступающим 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
сюда :) 23.08.02 05:16  Число просмотров: 6189
Автор: Biasha <Бяша> Статус: Member
Отредактировано 23.08.02 05:44  Количество правок: 2
<"чистая" ссылка>
Начнем со свеженайденного страшного 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 приобретает большую гибкость, большую функциональность. Цена – доверять самому себе (сообщениям своего десктопа и программам на нём запущеным).

Однако ж посмотрим, какие средства у нас есть на руках, чтобы бороться с данной проблемой. Во-первых, писать такие сервисы, открывающие интерактивные окна

Что такое "сервис, открывающий интерактивное окно"? Бывают интерактивные сервисы – те, что запускаются на WinSta0\Default, но что такое "интерактивное окно"?

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

Есть разница. Это "другое" взаимодействие неизбежно должно осуществляться с помощью защищаемых об'єктов. Поскольку нет иных разделяемых и не защищаемых, кроме GUI'шных, об'єктов, пригодных для взаимодействия через них (по крайней мере, я не знаю, и, кажется, так было где-то написано).

Далее, не совсем верно утверждение, что 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 – не запускает. А может и запускает – это не показатель см. мою прогу в программинг (она, правда, тоже не всех грешников показывает, но лучше чем просто смотреть на тип сервиса вручную, или на заголовки окон).

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

Я уже думаю, что трудно найти такие, которых нельзя поймать :)
<site updates> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2020 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach