информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
 Tailscale окончательно забанила... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
ну wm_timer все-таки не самое важное сообщение 15.12.02 21:43  Число просмотров: 1834
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Да и сложно придумать причину, по который обычная программа вздумает слать его чужому окну. А править всю систему передачи сообщений - это ж удавиться все тестировать.
<site updates>
Исправление уязвимости wm_timer 13.12.02 04:51  
Publisher: dl <Dmitry Leonov>
<"чистая" ссылка>
Исправление уязвимости WM_TIMER
Microsoft Security Bulletin http://www.microsoft.com/security/security_bulletins/ms02-071.asp

В Microsoft все-таки озаботились исправлением части того как бы бага, который обсуждался в конце лета [ http://www.bugtraq.ru/review/archive/2002/31-08-02.html ].
Напоминаю суть проблемы. Находим в системе крутящиеся процессы с более высокими правами, чем интерактивный пользователь, которые способны принимать оконные сообщение, и находим там что-нибудь типа поля ввода. Далее заполняем это поле своим кодом, отправив соответствующее сообщение. Но этот код надо еще как-то выполнить, и тут на помощь приходит сообщение WM_TIMER, которое в одном из своих вариантов может приходить с адресом callback-функции. Устанавливаем этот адрес куда-нибудь в район нашего засланного кода и получаем его исполнение с повышенными правами.
Как уже говорилось ранее [ http://www.bugtraq.ru/review/archive/2002/31-08-02.html ], в принципе, в системе есть все средства для написания кода, не подверженного...

Полный текст
интересно то что 13.12.02 10:12  
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
<"чистая" ссылка>
получив сообщение о данной уязвимости М$ ответили что это не баг а фича...
интересно то что 13.12.02 17:49  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
И, что характерно, они не так уж неправы. А потом, похоже, решили, что исправить малой кровью работу с WM_TIMER проще, чем пытаться переучивать толпы программистов :) Но это все равно не до конца решает проблему - впихнуть свой код через сообщения в другой процесс по-прежнему можно, вопрос лишь в том, чтобы найти новый способ его выполнить.
интересно то что 15.12.02 18:35  
Автор: buggzy Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> И, что характерно, они не так уж неправы. А потом, похоже,
> решили, что исправить малой кровью работу с WM_TIMER проще,
> чем пытаться переучивать толпы программистов :) Но это все

или же дело в том, что в MS-продуктах такое тоже встречается. зато теперь понятно, почему не было патча для GetAd - не стали отвлекаться на частности

> равно не до конца решает проблему - впихнуть свой код через

хех, user-defined данные всегда и на любой системе можно будет впихнуть в поля ввода. они ведь для этого и предназначены :) а делается ли это через messages или через какую-то другую систему взаимодействия - не так уж и важно...
Кстати, можно решить проблему радикально (по крайней мере для Messages), но они почему-то её не решают. 15.12.02 20:21  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 15.12.02 20:32  Количество правок: 2
<"чистая" ссылка>
Дело в том, что в винде отправкой сообщений занимается... назовём его Message Server. Он, определив, что ЛЮБОЕ сообщение заслано из ЧУЖОГО процесса, может просто имперсонировать поток-получатель под процесс-источник. Вуаля! Другое дело, что это может сказаться на работе огромной массы приложений, слишком много всего тестировать...
интересно то что 15.12.02 19:59  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
> или же дело в том, что в MS-продуктах такое тоже
> встречается. зато теперь понятно, почему не было патча для
> GetAd - не стали отвлекаться на частности

Ну если им верить, патч для WM_TIMER уже входит в SP1 для XP. А в последнем патче они все-таки решили и свои сервисы подправить.
Сорри, я заходил по ссылке, но так и не дорубил, КАК они это исправили. Имперсонируют поток, что ли, во время отработки WM_Timer? 14.12.02 10:51  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
а подробностей и нет 15.12.02 19:54  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Скорее всего, запрещают посылать WM_TIMER с callback'ом в чужие окна.
Во прикол. Это называется «бесполезно переучивать других программистов». Хорошо, если все мелкософтовые приложения выдержат такое надругательство. Ну да ладно... Это в их стиле ;-)) 15.12.02 20:10  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
ну wm_timer все-таки не самое важное сообщение 15.12.02 21:43  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Да и сложно придумать причину, по который обычная программа вздумает слать его чужому окну. А править всю систему передачи сообщений - это ж удавиться все тестировать.
1




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


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