Shatter attack

Тема shatter attack привлекла широкий интерес в сообществе специалистов по безопасности в августе 2002 года после публикации работы Криса Паджетта под названием «Exploiting design flaws in the Win32 API for privilege escalation»^[2]. В статье, в которой впервые был использован термин «shatter attack», описан процесс, при котором приложение может выполнять произвольный код в другом приложении. Это становилось возможным, поскольку Windows разрешает непривилегированным приложениям отправлять сообщения в цикл сообщений приложения с более высоким уровнем привилегий, причём некоторые сообщения могут содержать адрес функции обратного вызова в адресном пространстве приложения в качестве параметра. Если злоумышленнику удаётся поместить свою строку в память привилегированного приложения (например, вставив шелл-код в поле ввода) по известному адресу, то затем он может отправлять сообщения WM_TIMER с параметрами функции обратного вызова, указывающими на эту строку.

Спустя несколько недель после публикации данной работы компания Microsoft прокомментировала проблему следующим образом: «В статье верно указано, что такая ситуация существует, и верно описано её влияние. … Ошибка же заключается в утверждении, что это недостаток Windows. На самом деле, проблема заключается в конкретной высокопривилегированной службе. По замыслу, все службы в интерактивном рабочем столе — равноправные участники и могут делать друг другу запросы. В результате, все службы интерактивного рабочего стола фактически располагают привилегиями, соответствующими самой высокопривилегированной службе.»^[3]

В декабре 2002 года Microsoft выпустила обновление для Windows NT 4.0, Windows 2000 и Windows XP, устранившее некоторые способы эксплуатации этой уязвимости^[4]. Однако это было лишь частичным решением, поскольку исправление распространялось только на сервисы самой Windows, подверженные такому способу атаки; базовый изъян архитектуры оставался и мог быть использован для атаки на другие приложения или сторонние службы^[5]. В Windows Vista компания Microsoft решила проблему двумя способами: во-первых, локальные пользователи больше не входят в систему в сеанс с номером 0, тем самым разделяя цикл сообщений пользовательской сессии и системных служб с высокими привилегиями, загружаемых в Session 0. Во-вторых, была добавлена функция изоляции привилегий пользовательского интерфейса (UIPI), позволяющая защищать процессы от shatter attack путём присвоения каждому процессу уровня целостности^[6]. Попытки отправить сообщения процессу с более высоким уровнем целостности будут отклонены, даже если оба процесса принадлежат одному пользователю. Тем не менее, не все взаимодействия между процессами с разными уровнями целостности блокируются механизмом UIPI^[6]. Например, Internet Explorer 7 использует UIPI для ограничения возможностей компонент отображения взаимодействовать с остальной системой.

Архитектура создания сессий была переработана в Windows Vista и Windows Server 2008 для дополнительной защиты от shatter attack: вход локальных пользователей был перенесён из сеанса 0 в сеанс 1, тем самым процессы пользователя были изолированы от системных служб, потенциально подверженных атаке^[7][8].

Однако такая схема приводит к проблемам обратной совместимости, поскольку часть программного обеспечения была рассчитана на работу службы в одной сессии с вошедшим пользователем. Для поддержки такого сценария в Windows Vista и Windows Server 2008 была введена служба Windows «Interactive Services Detection», позволяющая пользователю открывать диалоги, созданные интерактивными службами. Пользователю показывалось окно с предложением переключиться в сеанс 0 для взаимодействия с диалогом^[9]. В Windows 10 Creators Update эта возможность была удалена^[10].