D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Команда The Binarly REsearch исследует, каким образом креши парсеров прошивки могут быть использованы атакующими для достижения arbitrary code execution с привилегиями прошивки во время процесса загрузки.
В экосистеме прошивки, устранение и исправление любого бага имеет решающее значение, поскольку даже один flaw может значительно подорвать безопасность всей платформы. В этом посте мы доказываем серьезность багов, которые мы обнаружили во время изучения LogoFAIL , путем создания PoC на реальном устройстве со включенными современными средствами защиты прошивки(а именно - Intel Boot Guard и Secure Boot).
В частности, мы демонстрируем, как мы превратили один креш, найденный нашим фаззером, в arbitrary code execution, во время фазы DXE.
В самом деле, через пару дней после наших презентаций, разработчики Target Software Fuzzer для SIMICS (TSFFS) опубликовали туториал , который показывает, как TSFFS может быть использован для фазза и BMP парсера, включенного в референс-код EDK2. Туториал так же включает ссылку на существующий фаззер для этого парсера, который был разработан, как часть HBFA. Так как мы не знали о существовании такого фаззера, мы хотели бы поблагодарить авторов TSFFS за то, что они обратили на него наше внимание.
Выбор креша
Наш фаззер нашел несколько крешей на тестовом устройстве - Lenovo ThinkCentre M70s Gen 2, теперь нам нужно выбрать один креш, как стартовую точку, для создания proof-of-concept.
Мы анализировали различные корневые причины выявленных багов, и наконец выбрали integer overflow в PNG парсере. Мы выбрали этот баг, потому что он влияет на формат файла, с которым "легко" работать, а так же потому что он легко приводит нас к heap overflow с arbitrary content и arbitrary size.
До углубления в детали техники эксплойтации, которые мы использовали, картинка сверху демонстрирует общий взгляд на то, как этот PNG парсер работает. Сперва парсер определяет местонахождение различных чанков в PNG, затем он извлекает глобальную информацию из IHDR чанка, такую, как: ширина и высота. В то время, когда все чанки IDAT, которые хранят фактические данные PNG, сконцентрированны в single buffer(На рисунке называются Compressed IDAT чанки). Затем парсер выделяет все buffer'ы, необходимые для обработки изображения, и наконец, распаковывает IDAT чанки в другой буффер, который мы называем OutputBuffer.
Сниппет сверху показывает корневую причину выбранного креша: integer overflow на размере, используеммом для выделения OutputBuffer. Так как PngWidth относиться к ширине, содержащайся в IHDR чанке, атакующий может увеличить это значение, так что результатом 32-битного умножения станет overflow(к примеру - 2 * 0x80000040 = 0x80).
Изза этого integer overflow, атакующий может выделить OutputBuffer, который недостаточно велик для содержания несжатых данных, что напрямую приводит к heap overflow с данными, контролируемыми атакущим в фазе распаковки PNG.
Но что именно может быть поврежденно с этим heap overflow? Дабы ответить на этот вопрос, мы вернемся к рисовальной доске и разберем, как работает UEFI heap.
UEFI Heap является pool-based. Это означает, что он хранит набор pool'ов для разных типов памяти - изображение сверху показывает, что pool асоциирован с типом памяти EfiBootServicesData. Каждый pool содержит набор чанков памяти (представленных объектом POOL_FREE), которые распределены по размеру, и используются для выполнения запросов на выделение памяти. Для примера - когда EFI_BOOT_SERVICES->AllocatePool вызван, heap manager выбирает корректный свободный лист, основываясь на размере запрашиваемого выделения, отвязывает первый элемент POOL_FREE, и возвращает выделенный чанк вызывателю. Выделенный чанк обёрнут с POOL_HEAD и POOL_TAIL объектами, то есть когда EFI_BOOT_SERVICES->FreePool вызван на чанк, heap manager может получить все метаданные, необходимые для возвращения этого чанка в соответствующий свободный лист.
К сожалению, у нас нет возможности дебаггинга на тестируемом девайсе: Intel Direct Connect Interface (DCI) не представлен на новых CPU, а Intel Boot Guard препятствует инжекту любых стабов для дебаггинга в рантайм прошивки. По этой причине, мы не можем проверить состояние heap memory в момент совершения overflow, и поэтому мы не знаем, что может быть перезаписанно и повреждено в момент overflow.
Одна из особенностей UEFI заключается в том, что используемая в процессе загрузки память, не очищается при передаче управления к операционной системе, поэтому она сохраняется после загрузки и может быть проверена из операционной системы. Скриншот ниже демонстрирует, что OutputBuffer может быть найден поиском паттерна “BRLYBRLY”, который получается в результате распаковки чанков данных PNG. С первого взгляда это понимание, похоже, определяет, что храниться после OutputBuffer.
Однако этот контент памяти не является снапшотом памяти, во время overflow, больше тем, что осталось после передачи контроля операционной системе. По этой причине, чанк начинающийся с адреса 0x82c83f90 - это не то, что присутствует по время overflow и может быть повреждено, а последний объект, который был выделен в этом месте кода UEFI.
Для преодоления данной проблемы, мы используем следующее понимание, которое мы обнаружили во время прочитывания исходного кода EFI_BOOT_SERVICES->FreePool. Как мы можем видеть в следующем сниппете, FreePool сразу же возвращает ошибку, когда подпись освобождаемого чанка не совпадает с POOL_HEAD_SIGNATURE (определен, как “phd0”).
Это значит, что путем поломки подписи выделенного чанка после OutputBuffer, мы можем принудить FreePool к возврату ошибки, и чанк будет возвращен в free list'ы, и поэтому он не будет использоваться снова для будущих выделений памяти. Эту техника, которую мы не видели задокументированной где-либо, эффективно консервирует содержимое выделенного чанка, что позволяет атакующему инспектировать его с ОС.
Heap overflow часто требует сильного контроля состояния heap. До самого overflow, атакующий обычно делает несколько выделений и невыделений в последовательности arbitrary, с целью "промассировать" heap, и выбрать какой объект выделен после того, который был переполнен. В нашем сценарии, несмотря на отсутствие сильных primitive, мы обнаружили, что на состояние heap можно влиять, путем включения определенных PNG чанков (к прим., PLTE и gAMA) в конечном изображении PNG и изменяя их размеры.
Мы попробовали базовую технику массирования heap с ращным порядком чанков PNG, и остановились после пары попыток, когла обнаружили, что OutputBuffer был веделен до объекта PROTOCOL_ENTRY.
Мы сразу поняли, что объект PROTOCOL_ENTRY станет мощной целью для повреждения, так как протоколы являются основной концепцией в UEFI и PROTOCOL_ENTRY содержит множество указателей к объектам протокола EFI, и множество из них, в свою очередь, содержат указатели функций.
Повреждение PROTOCOL_ENTRY
Объект PROTOCOL_ENTRY используется для репрезентации EFI протокола и всего , что вращается вокруг него. Предыдущий скриншот показывает определение PROTOCOL_ENTRY, взятое из референс-кода EDK2. Поле protocolID используется для хранения GUID протокола, представленного этим protocol entry. Как будет показано на следующей диаграме - поле AllEntries вместо этого используется референс-кодом UEFI для отслеживания различных PROTOCOL_ENTRY в круговом дву-связном списке, корнем которого является глобальная переменная mProtocolDatabase.
Этот лист является довольно важным, поскольку через него проходит, к примеру - EFI_BOOT_SERVICES->LocateProtocol, ради поиска определенного протокола. Из поля Protocols в PROTOCOL_ENTRY мы можем достигнуть его PROTOCOL_INTERFACE, который содержит указатель к фактическому интерфейсу, установленному EFI_BOOT_SERVICES->InstallProtocolInterface, в то время, когда поле Notify указывает на объект PROTOCOL_NOTIFY, используемый системой событий UEFI. Так как эти последние два поля в конечном итоге указывают на указатели функции, атакующий, способный повредить PROTOCOL_NOTIFY, может перезаписать любой из них для достижения arbitrary code execution, когда вызываются функции protocol interface или notification callback handler.
Для нашего proof-of-concept мы решили (пополь-)использовать систему событий EFI. Среди множества вещей, система разрешает модулю регистрировать callback handler, который вызван, когда определенный протокол установлен. Обчно это делается с помощью кода UEFI, путем вызова функций EFI_BOOT_SERVICES->CreateEvent и EFI_BOOT_SERVICES->RegisterProtocolNotify, которые создают и подготавливают объекты PROTOCOL_ENTRY и IEVENT. Когда определенный протокол установлен, функция CoreNotifyProtocolEntry поставит событие в очередь на уведомление в глобальный список, на который указывает gEventQueue. Фактическая отправка ожидающих событий, а значит, и вызов callback handler, произойдёт когда приоритет задачи будет установлен на значение ниже, чем приоритет уведомления, указанный в обхекте IEVENT.
Наш proof-of-concept имитирует регистрацию события, путем создания объектов PROTOCOL_ENTRY, PROTOCOL_NOTIFY и IEVENT в памяти и установки всех соединений между этих объектов. Таким образом, когда протокол, хранящийся в PROTOCOL_ENTRY, во время overflow будет установлен, а диспетчеры событий вызовут наш callback handler, и таким образом мы добьемся achieve arbitrary code execution.
Напоследок отметим, что в качестве GUID целевого протокола в записи протокола мы использовали протокол, который устанавливается сразу после вызова функции парсинга логотипа. Этот GUID может быть найден путем реверс-инжиниринга, или восстановления с помощью некоторых базовых техник форензики памяти список установленных протоколов(корень которого находится в mProtocolDatabase) из памяти UEFI, оставшейся после загрузки.
NVRAM + Shellcode + Second Stage
Последнее, что нам надо выяснить - это куда перенаправить control flow после вызова функции callback handler. Этот шаг очень упрощается из-за распространенной ошибки в конфигурации, которая не удаляет разрешения на исполнение из памяти, используемойлоя отображения переменных NVRAM. Другими словами - мы можем попросту сохранить шеллкод внутри переменной NVRAM, и эта память будет одновременно и исполняемой, и всегда отобрадаемой по одному и тому же адресу!
Когда arbitrary code execution достигнут во время фазы DXE - это гейм-овер для безопасности платформы. На этом этапе мы имеем полный контроль над памятью и дисками целевого устройства, включая операционную систему, которая будет запущена.
В частности, очень легко запустить буткит, такой как BlackLotus и модифицировать ОС, которая будет запущена после загрузки. Мы докажем это, путем расширения нашего изначального proof-of-concept до более продвинутого поведения. В конкретике, наш окончательный PoC будет способен выключать SecureBoot (это очень просто, так как требуется лишь установить глобальную переменную gSecutiry2 к NULL), и загружать с исполнением второй этап с диска. Второй этап заменяет текущий NTFS драйвер заменяется драйвером с поддержкой записи, что бы файлы можно было записывать в файловую систему Windows.
В видео с proof-of-concept мы демонстрировали arbitrary code execution во время DXE, путем отображения сообщения на мониторе, и показали, что наша усовершенствованная полезная нагрузка может создавать файл в файловой системе Windows.
Довольно интересно, что UEFI heap референс-кода EDK2 имплементирует системы защиты против heap overflow, называемые Heap Guard, которые полностью воспрепятствуют нашему proof of concept, обсуждаемому в этом посте. Эта защита работает путем размещения страницы с немаркированной памятью до и после каждого из выделений, то есть любой overflow будет немедленно заблокирован.
Однако, мы обнаружили коммент в источниках EDK2, который гласит, что Heap Guard предназначен только для целей дебаггингa, и его не следует подключать в любом из продуктов. Эта сноска подчеркивает наш опыт, так как мы не видели любой системы, где это средство защиты включено "в боевом режиме"
Аналогично, что референс-код так же содержит логику для отключения исполнения кода, хранящегося в зоне NVRAM, который можно сделать попросту правильно настроив таблицы. Единственные системы, где мы нашли это средство звщиты включенным и правильно сконфигурированным, оказались ARM системы и некоторые серверы. Это всё равно не остановит экспойтацию, поскольку arbitrary code execution может быть достигнут с помощью более продвинутых техник эксплойтации(к примеру, ROP).
ПЕРЕВОД H0unT
ОРИГИНАЛ https://binarly.io/posts/inside_the_logofail_poc_from_integer_overflow_to_arbitrary_code_execution/
В экосистеме прошивки, устранение и исправление любого бага имеет решающее значение, поскольку даже один flaw может значительно подорвать безопасность всей платформы. В этом посте мы доказываем серьезность багов, которые мы обнаружили во время изучения LogoFAIL , путем создания PoC на реальном устройстве со включенными современными средствами защиты прошивки(а именно - Intel Boot Guard и Secure Boot).
В частности, мы демонстрируем, как мы превратили один креш, найденный нашим фаззером, в arbitrary code execution, во время фазы DXE.
LogoFAIL Errata
После демонстрации LogoFail на Black Hat Europe и H2HC - мы получили достаточно много позитивного фидбека от коммьюнити, а так же мы мы отметили улучшения и исправления в нашей работе. В частности, во время разговора, мы утверждали, что ни одна из библиотек образов, используемых в современных UEFI прошивках никогда не тестировалась OEM или IBV. Это были чистые домыслы, основанные на наших знаниях и результатах экспериментов, и мы должны прояснить это гораздо лучше.
В самом деле, через пару дней после наших презентаций, разработчики Target Software Fuzzer для SIMICS (TSFFS) опубликовали туториал , который показывает, как TSFFS может быть использован для фазза и BMP парсера, включенного в референс-код EDK2. Туториал так же включает ссылку на существующий фаззер для этого парсера, который был разработан, как часть HBFA. Так как мы не знали о существовании такого фаззера, мы хотели бы поблагодарить авторов TSFFS за то, что они обратили на него наше внимание.
Выбор креша
Мы анализировали различные корневые причины выявленных багов, и наконец выбрали integer overflow в PNG парсере. Мы выбрали этот баг, потому что он влияет на формат файла, с которым "легко" работать, а так же потому что он легко приводит нас к heap overflow с arbitrary content и arbitrary size.
До углубления в детали техники эксплойтации, которые мы использовали, картинка сверху демонстрирует общий взгляд на то, как этот PNG парсер работает. Сперва парсер определяет местонахождение различных чанков в PNG, затем он извлекает глобальную информацию из IHDR чанка, такую, как: ширина и высота. В то время, когда все чанки IDAT, которые хранят фактические данные PNG, сконцентрированны в single buffer(На рисунке называются Compressed IDAT чанки). Затем парсер выделяет все buffer'ы, необходимые для обработки изображения, и наконец, распаковывает IDAT чанки в другой буффер, который мы называем OutputBuffer.
Сниппет сверху показывает корневую причину выбранного креша: integer overflow на размере, используеммом для выделения OutputBuffer. Так как PngWidth относиться к ширине, содержащайся в IHDR чанке, атакующий может увеличить это значение, так что результатом 32-битного умножения станет overflow(к примеру - 2 * 0x80000040 = 0x80).
Изза этого integer overflow, атакующий может выделить OutputBuffer, который недостаточно велик для содержания несжатых данных, что напрямую приводит к heap overflow с данными, контролируемыми атакущим в фазе распаковки PNG.
Но что именно может быть поврежденно с этим heap overflow? Дабы ответить на этот вопрос, мы вернемся к рисовальной доске и разберем, как работает UEFI heap.
Внутренности UEFI Heap
UEFI Heap является pool-based. Это означает, что он хранит набор pool'ов для разных типов памяти - изображение сверху показывает, что pool асоциирован с типом памяти EfiBootServicesData. Каждый pool содержит набор чанков памяти (представленных объектом POOL_FREE), которые распределены по размеру, и используются для выполнения запросов на выделение памяти. Для примера - когда EFI_BOOT_SERVICES->AllocatePool вызван, heap manager выбирает корректный свободный лист, основываясь на размере запрашиваемого выделения, отвязывает первый элемент POOL_FREE, и возвращает выделенный чанк вызывателю. Выделенный чанк обёрнут с POOL_HEAD и POOL_TAIL объектами, то есть когда EFI_BOOT_SERVICES->FreePool вызван на чанк, heap manager может получить все метаданные, необходимые для возвращения этого чанка в соответствующий свободный лист.
UEFI Heap Overflow
Как часто бывает в heap allocators, выделенные чанки и свободные чанки со-существуют в одинаковых регионах памяти. По этой причине - атакующий, эксплойтирующий heap overflow, может повредить как и выделенный чанк, так и свободный, в зависимости от того, что храниться после buffer overflow.
К сожалению, у нас нет возможности дебаггинга на тестируемом девайсе: Intel Direct Connect Interface (DCI) не представлен на новых CPU, а Intel Boot Guard препятствует инжекту любых стабов для дебаггинга в рантайм прошивки. По этой причине, мы не можем проверить состояние heap memory в момент совершения overflow, и поэтому мы не знаем, что может быть перезаписанно и повреждено в момент overflow.
Одна из особенностей UEFI заключается в том, что используемая в процессе загрузки память, не очищается при передаче управления к операционной системе, поэтому она сохраняется после загрузки и может быть проверена из операционной системы. Скриншот ниже демонстрирует, что OutputBuffer может быть найден поиском паттерна “BRLYBRLY”, который получается в результате распаковки чанков данных PNG. С первого взгляда это понимание, похоже, определяет, что храниться после OutputBuffer.
Однако этот контент памяти не является снапшотом памяти, во время overflow, больше тем, что осталось после передачи контроля операционной системе. По этой причине, чанк начинающийся с адреса 0x82c83f90 - это не то, что присутствует по время overflow и может быть повреждено, а последний объект, который был выделен в этом месте кода UEFI.
Для преодоления данной проблемы, мы используем следующее понимание, которое мы обнаружили во время прочитывания исходного кода EFI_BOOT_SERVICES->FreePool. Как мы можем видеть в следующем сниппете, FreePool сразу же возвращает ошибку, когда подпись освобождаемого чанка не совпадает с POOL_HEAD_SIGNATURE (определен, как “phd0”).
Это значит, что путем поломки подписи выделенного чанка после OutputBuffer, мы можем принудить FreePool к возврату ошибки, и чанк будет возвращен в free list'ы, и поэтому он не будет использоваться снова для будущих выделений памяти. Эту техника, которую мы не видели задокументированной где-либо, эффективно консервирует содержимое выделенного чанка, что позволяет атакующему инспектировать его с ОС.
Фен Шуй Heap
Вкратце, используя техники, описанные в предыдущих секциях - мы можем инспектировать с операционки чанк, выделенный после OutputBuffer, а так же какой объект был поврежден. Осталось только найти хорошую цель для повреждения, и использовать их для code execution.
Heap overflow часто требует сильного контроля состояния heap. До самого overflow, атакующий обычно делает несколько выделений и невыделений в последовательности arbitrary, с целью "промассировать" heap, и выбрать какой объект выделен после того, который был переполнен. В нашем сценарии, несмотря на отсутствие сильных primitive, мы обнаружили, что на состояние heap можно влиять, путем включения определенных PNG чанков (к прим., PLTE и gAMA) в конечном изображении PNG и изменяя их размеры.
Мы попробовали базовую технику массирования heap с ращным порядком чанков PNG, и остановились после пары попыток, когла обнаружили, что OutputBuffer был веделен до объекта PROTOCOL_ENTRY.
Мы сразу поняли, что объект PROTOCOL_ENTRY станет мощной целью для повреждения, так как протоколы являются основной концепцией в UEFI и PROTOCOL_ENTRY содержит множество указателей к объектам протокола EFI, и множество из них, в свою очередь, содержат указатели функций.
Повреждение PROTOCOL_ENTRY
Объект PROTOCOL_ENTRY используется для репрезентации EFI протокола и всего , что вращается вокруг него. Предыдущий скриншот показывает определение PROTOCOL_ENTRY, взятое из референс-кода EDK2. Поле protocolID используется для хранения GUID протокола, представленного этим protocol entry. Как будет показано на следующей диаграме - поле AllEntries вместо этого используется референс-кодом UEFI для отслеживания различных PROTOCOL_ENTRY в круговом дву-связном списке, корнем которого является глобальная переменная mProtocolDatabase.
Этот лист является довольно важным, поскольку через него проходит, к примеру - EFI_BOOT_SERVICES->LocateProtocol, ради поиска определенного протокола. Из поля Protocols в PROTOCOL_ENTRY мы можем достигнуть его PROTOCOL_INTERFACE, который содержит указатель к фактическому интерфейсу, установленному EFI_BOOT_SERVICES->InstallProtocolInterface, в то время, когда поле Notify указывает на объект PROTOCOL_NOTIFY, используемый системой событий UEFI. Так как эти последние два поля в конечном итоге указывают на указатели функции, атакующий, способный повредить PROTOCOL_NOTIFY, может перезаписать любой из них для достижения arbitrary code execution, когда вызываются функции protocol interface или notification callback handler.
Система Событий UEFI
Для нашего proof-of-concept мы решили (пополь-)использовать систему событий EFI. Среди множества вещей, система разрешает модулю регистрировать callback handler, который вызван, когда определенный протокол установлен. Обчно это делается с помощью кода UEFI, путем вызова функций EFI_BOOT_SERVICES->CreateEvent и EFI_BOOT_SERVICES->RegisterProtocolNotify, которые создают и подготавливают объекты PROTOCOL_ENTRY и IEVENT. Когда определенный протокол установлен, функция CoreNotifyProtocolEntry поставит событие в очередь на уведомление в глобальный список, на который указывает gEventQueue. Фактическая отправка ожидающих событий, а значит, и вызов callback handler, произойдёт когда приоритет задачи будет установлен на значение ниже, чем приоритет уведомления, указанный в обхекте IEVENT.
Наш proof-of-concept имитирует регистрацию события, путем создания объектов PROTOCOL_ENTRY, PROTOCOL_NOTIFY и IEVENT в памяти и установки всех соединений между этих объектов. Таким образом, когда протокол, хранящийся в PROTOCOL_ENTRY, во время overflow будет установлен, а диспетчеры событий вызовут наш callback handler, и таким образом мы добьемся achieve arbitrary code execution.
Напоследок отметим, что в качестве GUID целевого протокола в записи протокола мы использовали протокол, который устанавливается сразу после вызова функции парсинга логотипа. Этот GUID может быть найден путем реверс-инжиниринга, или восстановления с помощью некоторых базовых техник форензики памяти список установленных протоколов(корень которого находится в mProtocolDatabase) из памяти UEFI, оставшейся после загрузки.
NVRAM + Shellcode + Second Stage
Когда arbitrary code execution достигнут во время фазы DXE - это гейм-овер для безопасности платформы. На этом этапе мы имеем полный контроль над памятью и дисками целевого устройства, включая операционную систему, которая будет запущена.
В частности, очень легко запустить буткит, такой как BlackLotus и модифицировать ОС, которая будет запущена после загрузки. Мы докажем это, путем расширения нашего изначального proof-of-concept до более продвинутого поведения. В конкретике, наш окончательный PoC будет способен выключать SecureBoot (это очень просто, так как требуется лишь установить глобальную переменную gSecutiry2 к NULL), и загружать с исполнением второй этап с диска. Второй этап заменяет текущий NTFS драйвер заменяется драйвером с поддержкой записи, что бы файлы можно было записывать в файловую систему Windows.
Proof of concept
Cледующее видео показывает, как эксплойтация LogoFAIL выглядит на тестовом устройстве. После логина, мы запускаем терминал с привилегиями админа. Затем мы проверяем включены ли Secure Boot и Intel Boot Guard (Verified Boot), и запускаем LogoFAIL proof of concept. PoC готовит все требуемые объекты UEFI, сохраняет вредоносный PNG файл в переменную NVRAM, и в конце концов, перезагружает устр-во. Во время процесса загрузки, системная прошивка пропарсит инжектированный PNG, и запустит heap overflow, который даст результат в виде повреждения памяти, которое мы обсуждали в предыдущих секциях.
В видео с proof-of-concept мы демонстрировали arbitrary code execution во время DXE, путем отображения сообщения на мониторе, и показали, что наша усовершенствованная полезная нагрузка может создавать файл в файловой системе Windows.
Защиты
Довольно интересно, что UEFI heap референс-кода EDK2 имплементирует системы защиты против heap overflow, называемые Heap Guard, которые полностью воспрепятствуют нашему proof of concept, обсуждаемому в этом посте. Эта защита работает путем размещения страницы с немаркированной памятью до и после каждого из выделений, то есть любой overflow будет немедленно заблокирован.
Однако, мы обнаружили коммент в источниках EDK2, который гласит, что Heap Guard предназначен только для целей дебаггингa, и его не следует подключать в любом из продуктов. Эта сноска подчеркивает наш опыт, так как мы не видели любой системы, где это средство защиты включено "в боевом режиме"
Аналогично, что референс-код так же содержит логику для отключения исполнения кода, хранящегося в зоне NVRAM, который можно сделать попросту правильно настроив таблицы. Единственные системы, где мы нашли это средство звщиты включенным и правильно сконфигурированным, оказались ARM системы и некоторые серверы. Это всё равно не остановит экспойтацию, поскольку arbitrary code execution может быть достигнут с помощью более продвинутых техник эксплойтации(к примеру, ROP).
Завершающие мысли
В этом блог посте мы показали, как мы превротили integer overflow в heap overflow с arbitrary code execution. Техники, которые мы обсуждали в этои блоге очень универсальны и тесно связаны с экосистемой UEFI, поэтому их можно применить для экслойтации любого heap overflow, но так же будет сложно, если вообще возможно, исправить без применения более мощных средств защиты, предназначенных для heap corruptions(например, Heap Guard). Это так же один из первых heap эксплойтов, задокументированных в UEFI, поэтому мы не исключаем, что в будущем могут быть обнаружены более простые и стабильные методы, что еще больше снизит планку эксплойтации.ПЕРЕВОД H0unT
ОРИГИНАЛ https://binarly.io/posts/inside_the_logofail_poc_from_integer_overflow_to_arbitrary_code_execution/