Исправление уязвимости WM_TIMER dl // 13.12.02 04:51
В Microsoft все-таки озаботились исправлением части того как бы бага, который обсуждался в конце лета.
[Не забывайте при копировании материала указывать полный адрес источника: http://www.bugtraq.ru/rsn/archive/2002/12/11.html]
Напоминаю суть проблемы. Находим в системе крутящиеся процессы с более высокими правами, чем интерактивный пользователь, которые способны принимать оконные сообщение, и находим там что-нибудь типа поля ввода. Далее заполняем это поле своим кодом, отправив соответствующее сообщение. Но этот код надо еще как-то выполнить, и тут на помощь приходит сообщение WM_TIMER, которое в одном из своих вариантов может приходить с адресом callback-функции. Устанавливаем этот адрес куда-нибудь в район нашего засланного кода и получаем его исполнение с повышенными правами.
Как уже говорилось ранее, в принципе, в системе есть все средства для написания кода, не подверженного этой атаке. Другое дело, что это ж надо еще заставить себя так написать. Видимо, в Microsoft решили не надеяться на сознательность программистов (тем более, что и в родных сервисах, похоже, не все чисто), и решили с этой плюхой побороться. Исправлять всю систему передачи сообщений было бы слишком накладно, а вот работу с WM_TIMER исправили. А заодно от греха поправили и часть системных сервисов.
И, что характерно, они не так уж неправы. А потом, похоже, решили, что исправить малой кровью работу с 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
Скорее всего, запрещают посылать WM_TIMER с callback'ом в чужие окна.
Во прикол. Это называется «бесполезно переучивать других программистов». Хорошо, если все мелкософтовые приложения выдержат такое надругательство. Ну да ладно... Это в их стиле ;-))15.12.02 20:10 Автор: HandleX <Александр М.> Статус: The Elderman
Да и сложно придумать причину, по который обычная программа вздумает слать его чужому окну. А править всю систему передачи сообщений - это ж удавиться все тестировать.
подробно о проекте
Анализ криптографических сетевых...
