Напоминаю суть проблемы. Находим в системе крутящиеся процессы с более высокими правами, чем интерактивный пользователь, которые способны принимать оконные сообщение, и находим там что-нибудь типа поля ввода. Далее заполняем это поле своим кодом, отправив соответствующее сообщение. Но этот код надо еще как-то выполнить, и тут на помощь приходит сообщение WM_TIMER, которое в одном из своих вариантов может приходить с адресом callback-функции. Устанавливаем этот адрес куда-нибудь в район нашего засланного кода и получаем его исполнение с повышенными правами.

Как уже говорилось ранее, в принципе, в системе есть все средства для написания кода, не подверженного этой атаке. Другое дело, что это ж надо еще заставить себя так написать. Видимо, в Microsoft решили не надеяться на сознательность программистов (тем более, что и в родных сервисах, похоже, не все чисто), и решили с этой плюхой побороться. Исправлять всю систему передачи сообщений было бы слишком накладно, а вот работу с WM_TIMER исправили. А заодно от греха поправили и часть системных сервисов.

Источник: Microsoft Security Bulletin

теги: microsoft  |  предложить новость  |  обсудить  |  все отзывы (9)

[6741]

назад «  » вперед

аналогичные материалы Microsoft обещает радикально усилить безопасность Windows в следующем году // 19.11.24 17:09 Microsoft Authenticator теряет пользовательские аккаунты // 05.08.24 22:21 Облачнолазурное // 31.07.24 17:34 Microsoft планирует избавиться от NTLM // 15.10.23 18:40 Microsoft убивает VBScript // 11.10.23 23:46 В Microsoft Bing Chat пролезла вредоносная реклама // 30.09.23 15:05 Microsoft прикрывает Visual Studio for Mac // 30.08.23 19:17

последние новостиBugTraq.Ru: последние новости Microsoft обещает радикально усилить безопасность Windows в следующем году // 19.11.24 17:09 Ядро Linux избавляется от российских мейнтейнеров // 23.10.24 23:10 20 лет Ubuntu // 20.10.24 19:11 Tailscale окончательно забанила российские адреса // 02.10.24 18:54 Прекращение работы антивируса Касперского в США // 30.09.24 17:30 Microsoft Authenticator теряет пользовательские аккаунты // 05.08.24 22:21 Облачнолазурное // 31.07.24 17:34

Комментарии: интересно то что 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> <"чистая" ссылка> Да и сложно придумать причину, по который обычная программа вздумает слать его чужому окну. А править всю систему передачи сообщений - это ж удавиться все тестировать.

<добавить комментарий>