MSIE версии 6 и выше позволяет внедрять в страницы элементы управления .NET (иногда именуемые элементами пользовательского интерфейса - UI Controls). Эти элементы управления являются бинарными файлами .NET, которые выполняются в "песочнице" (т.е. в ограниченной контролируемой среде) внутри процесса браузера и могут восприниматься как .NET-эквивалент Java-апплетов, либо как более безопасная замена элементов управления ActiveX. Загружаются эти элементы управления браузером за счет использования тега <OBJECT>:
PHP код:
<OBJECT classid="ControlName.dll#Namespace.ClassName">
Синтаксис схож с тем, как внедряются элементы ActiveX, но есть несколько ключевых отличий:
- Вместо GUID атрибут classid содержит URL, указывающий на местоположение исполняемого файла .NET, а также пространство имен и название класса для элемента управления.
- В конфигурации MSIE по умолчанию элементы управления .NET могут быть внедрены в любой странице в зоне Internet. Это поведение можно изменить через закладку настройки безопасности MSIE.
- В отличие от ActiveX, не выводится никаких предупреждений, когда браузер встречает неизвестный прежде элемент управления .NET. Это связано с тем, что такие элементы управления выполняются в "песочнице" и рассматриваются как безопасные независимо от места своего происхождения, подобно тому как рассматриваются Java-апплеты.
Библиотеки .NET являются PE-файлами с дополнительным заголовком, описывающим классы и .NET байткод, содержащийся в библиотеке. Байткод является скомпилированным кодом на Intermediate Language (IL), выполняемым виртуальной машиной Common Language Runtime (CLR). Когда библиотека .NET загружается в браузер, средой выполнения проверяется, что она содержит только IL-код и не содержит исполняемого кода, который бы мог выполняется непосредственно процессором. Фактически же выполняется довольно обширный набор проверок с целью удостовериться, что загружаемый файл является корректным.
Однако, поскольку формат библиотек .NET по структуре является надмножеством формата PE-файлов, CLR отображает их в память как обычные исполняемые файлы. Это значит, что ядро разбирает PE-заголовок и загружает все секции в память точно так же, как и для обычных исполняемых файлов или DLL-библиотек. По ходу этого процесса ядро устанавливает разрешения для каждой секции в соответствии с флагами, прописанными для нее в PE-заголовке. Если бинарный файл содержит исполняемую секцию (т.е. секцию с соответствующим флагом в заголовке), то она будет загружена в память, и ее страницы будут помечены как исполняемые. Все это дает возможность злоумышленнику поместить исполняемый
код оболочки в секцию .text (обычное название для секции кода исполняемых файлов, собираемых Microsoft'овским компоновщиком) библиотеки .NET и сделать так, что этот код будет загружен в помеченные как исполняемые страницы памяти в контексте процесса браузера. В Windows XP адрес, по которому будет загружен исполняемый файл, зависит от значения image base, указанного в PE-заголовке этого файла, которое также контролируется злоумышленником.
Возможность разместить исполняемый
код оболочки по известному адресу в адресном пространстве обычно имеет первостепенное значение в успешном использовании уязвимости, связанной с нарушением содержимого памяти. Использование элементов управления .NET для размещения такого кода по ряду причину чрезвычайно полезной для злоумышленников:
- Злоумышленник может создать под такой код буфер произвольного размера.
- Злоумышленник не ограничен в том, какие значения байтов можно использовать в таком коде.
- Злоумышленник может также создавать произвольные сложные структуры данных и загружать их по известному адресу в памяти.
Мы можем, к примеру, поместить код оболочки в строку, используемую в конструкторе класса нашего элемента управления. Эта строка будет помещена в секции .text нашей .NET библиотеки и будет помечена как исполняемый код, когда наш компонент окажется загруженным. Эксплойт может использовать переполнение буфера ANI для того, чтобы перенаправить адрес возврата на указанный код и выполнить его.