Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | |
Кстати, можно решить проблему радикально (по крайней мере для Messages), но они почему-то её не решают. 15.12.02 20:21 Число просмотров: 1789
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 15.12.02 20:32 Количество правок: 2
|
|
Дело в том, что в винде отправкой сообщений занимается... назовём его Message Server. Он, определив, что ЛЮБОЕ сообщение заслано из ЧУЖОГО процесса, может просто имперсонировать поток-получатель под процесс-источник. Вуаля! Другое дело, что это может сказаться на работе огромной массы приложений, слишком много всего тестировать...
|
|
<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>
|
|
Да и сложно придумать причину, по который обычная программа вздумает слать его чужому окну. А править всю систему передачи сообщений - это ж удавиться все тестировать.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
