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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Во прикол. Это называется «бесполезно переучивать других программистов». Хорошо, если все мелкософтовые приложения выдержат такое надругательство. Ну да ладно... Это в их стиле ;-)) 15.12.02 20:10  Число просмотров: 1535
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
<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-2022 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach