С тех пор, как в 2016 году в Pwn2Own появилась категория виртуализации, побег от гостевого компьютера стал основным событием конкурса. Событие этого года не стало исключением. Другие побеги от гостя к хосту также проходили через программу ZDI в течение года. Фактически, VMware выпустила
Протокол динамической конфигурации хоста (DHCP)
Протокол динамической конфигурации хоста (DHCP) используется для динамического назначения и управления IP-адресами путем обмена сообщениями DHCP между клиентом и сервером DHCP. К сообщениям DHCP относятся DHCPDISCOVER, DHCPOFFER, DHCPRELEASE и некоторые другие. Все сообщения DCHP начинаются со следующей общей структуры заголовка:
Рисунок 1 - структура заголовка DHCP
Поле параметров сообщения DHCP содержит последовательность полей параметров . Структура поля параметров выглядит следующим образом:
Рисунок 2 - Опционная структура поля
Поле optionCode определяет тип опции. Значение optionCode составляет 0x35 и 0x3d для типа сообщения DHCP и параметров идентификатора клиента соответственно.
Сообщение DHCP должно содержать одну опцию типа сообщения DHCP . Для опции типа сообщения DHCP значение поля optionLength равно 1, а поле optionData указывает тип сообщения. Значение 1 указывает на сообщение DHCPDISCOVER, а значение 7 указывает на сообщение DHCPRELEASE. Это два типа сообщений, которые важны для этой уязвимости. DHCPDISCOVER транслируется клиентом для получения IP-адреса, и клиент отправляет DHCPRELEASE, чтобы освободить IP-адрес.
Уязвимость
В рабочей станции VMWare модуль vmnetdhcp.exe предоставляет службу DHCP-сервера для гостевых машин. Эта запись запуска устанавливается как служба Windows. Уязвимость возникает при отправке сообщения DHCPDISCOVER, за которым следует сообщение DHCPRELEASE, повторно на уязвимый DHCP-сервер.
Во время обработки сообщения DHCPRELEASE сервер DHCP вызывает vmnetdhcp! supersede_lease( vmnetdhcp+0x3160). Затем supersede_leaseфункция копирует данные из одной структуры аренды в другую. Структура аренды содержит такую информацию, как назначенный IP-адрес клиента, аппаратный адрес клиента, срок аренды, статус аренды и т. Д. Полная структура аренды выглядит следующим образом:
Рисунок 3 - Структура аренды
Для этой уязвимости важны поля uid и uid_len . Поле uid указывает на буфер, содержащий строковые данные из поля optionData идентификатора клиента . Поле uid_len указывает размер этого буфера.
Сначала supersede_lease проверяет, равны ли строковые данные, указанные соответствующими полями uid аренды источника и назначения. Если эти две строки совпадают, функция освобождает буфер, на который указывает поле uid аренды источника. После этого supersede_lease вызывает метод write_lease ( vmnetdhcp+016e0), передавая аренду назначения в качестве аргумента, чтобы записать аренду во внутреннюю таблицу.
Рисунок 4 - Сравните поля UID
Рисунок 5 - освобождает поле uid
В уязвимом состоянии, то есть когда сервер DHCPDISCOVER, за которым следует сообщение DHCPRELEASE, неоднократно принимается сервером, соответствующие поля uid структур аренды источника и назначения фактически указывают на одно и то же место в памяти. Функция supersede_lease не проверяет это условие. В результате, когда он освобождает память, указанную полем uid аренды источника, указатель uid аренды назначения становится зависающим указателем. Наконец, когда write_lease обращается к полю uid аренды назначения, возникает условие использования после освобождения (UAF).
Рисунок 6 - Запуск ошибки
Патч
VMware исправила эту ошибку и две ошибки меньшей серьезности с
Рисунок 7 - Сравнение патчей BinDiff
В исправленной версии supersede_lease после сравнения строк между соответствующими полями uid аренды источника и назначения он выполняет новую проверку, чтобы увидеть, действительно ли соответствующие поля uid ссылаются на один и тот же буфер. Если они есть, функция пропускает звонок бесплатно .
Поскольку в списке нет обходных путей, единственный способ убедиться, что вы защищены от этой ошибки, - это применить исправление.
Несмотря на то, что проблема хорошо понятна, ошибки UAF по-прежнему распространены в современном программном обеспечении. Фактически, 15% рекомендаций, которые мы
Источник:
Ссылка скрыта от гостей
для такой ошибки менее чем за неделю до соревнований этого года. В этой записи блога мы рассмотрим CVE-2020-3947, который был представлен в программе
Ссылка скрыта от гостей
(
Ссылка скрыта от гостей
) в конце декабря анонимным исследователем. Данная уязвимость затрагивает компонент DHCP-сервера VMware Workstation и может позволить злоумышленникам повысить привилегии гостевой ОС и выполнить код на хост-ОС.Протокол динамической конфигурации хоста (DHCP)
Протокол динамической конфигурации хоста (DHCP) используется для динамического назначения и управления IP-адресами путем обмена сообщениями DHCP между клиентом и сервером DHCP. К сообщениям DHCP относятся DHCPDISCOVER, DHCPOFFER, DHCPRELEASE и некоторые другие. Все сообщения DCHP начинаются со следующей общей структуры заголовка:
Рисунок 1 - структура заголовка DHCP
Поле параметров сообщения DHCP содержит последовательность полей параметров . Структура поля параметров выглядит следующим образом:
Рисунок 2 - Опционная структура поля
Поле optionCode определяет тип опции. Значение optionCode составляет 0x35 и 0x3d для типа сообщения DHCP и параметров идентификатора клиента соответственно.
Сообщение DHCP должно содержать одну опцию типа сообщения DHCP . Для опции типа сообщения DHCP значение поля optionLength равно 1, а поле optionData указывает тип сообщения. Значение 1 указывает на сообщение DHCPDISCOVER, а значение 7 указывает на сообщение DHCPRELEASE. Это два типа сообщений, которые важны для этой уязвимости. DHCPDISCOVER транслируется клиентом для получения IP-адреса, и клиент отправляет DHCPRELEASE, чтобы освободить IP-адрес.
Уязвимость
В рабочей станции VMWare модуль vmnetdhcp.exe предоставляет службу DHCP-сервера для гостевых машин. Эта запись запуска устанавливается как служба Windows. Уязвимость возникает при отправке сообщения DHCPDISCOVER, за которым следует сообщение DHCPRELEASE, повторно на уязвимый DHCP-сервер.
Во время обработки сообщения DHCPRELEASE сервер DHCP вызывает vmnetdhcp! supersede_lease( vmnetdhcp+0x3160). Затем supersede_leaseфункция копирует данные из одной структуры аренды в другую. Структура аренды содержит такую информацию, как назначенный IP-адрес клиента, аппаратный адрес клиента, срок аренды, статус аренды и т. Д. Полная структура аренды выглядит следующим образом:
Рисунок 3 - Структура аренды
Для этой уязвимости важны поля uid и uid_len . Поле uid указывает на буфер, содержащий строковые данные из поля optionData идентификатора клиента . Поле uid_len указывает размер этого буфера.
Сначала supersede_lease проверяет, равны ли строковые данные, указанные соответствующими полями uid аренды источника и назначения. Если эти две строки совпадают, функция освобождает буфер, на который указывает поле uid аренды источника. После этого supersede_lease вызывает метод write_lease ( vmnetdhcp+016e0), передавая аренду назначения в качестве аргумента, чтобы записать аренду во внутреннюю таблицу.
Рисунок 4 - Сравните поля UID
Рисунок 5 - освобождает поле uid
В уязвимом состоянии, то есть когда сервер DHCPDISCOVER, за которым следует сообщение DHCPRELEASE, неоднократно принимается сервером, соответствующие поля uid структур аренды источника и назначения фактически указывают на одно и то же место в памяти. Функция supersede_lease не проверяет это условие. В результате, когда он освобождает память, указанную полем uid аренды источника, указатель uid аренды назначения становится зависающим указателем. Наконец, когда write_lease обращается к полю uid аренды назначения, возникает условие использования после освобождения (UAF).
Рисунок 6 - Запуск ошибки
Патч
VMware исправила эту ошибку и две ошибки меньшей серьезности с
Ссылка скрыта от гостей
. Патч для адреса CVE-2020-3947 содержит изменения в одной функции: supersede_lease . Сравнение патчей supersede_lease в VMnetDHCP.exe версии 15.5.1.50853 с версией 15.5.2.54704 выглядит следующим образом:
Рисунок 7 - Сравнение патчей BinDiff
В исправленной версии supersede_lease после сравнения строк между соответствующими полями uid аренды источника и назначения он выполняет новую проверку, чтобы увидеть, действительно ли соответствующие поля uid ссылаются на один и тот же буфер. Если они есть, функция пропускает звонок бесплатно .
Поскольку в списке нет обходных путей, единственный способ убедиться, что вы защищены от этой ошибки, - это применить исправление.
Несмотря на то, что проблема хорошо понятна, ошибки UAF по-прежнему распространены в современном программном обеспечении. Фактически, 15% рекомендаций, которые мы
Ссылка скрыта от гостей
в 2019 году, были результатом состояния UAF. Будет интересно посмотреть, сохранится ли эта тенденция в 2020 году.Источник:
Ссылка скрыта от гостей