Не так давно я случайно обнаружил, что современные UEFI-совместимые прошивки имеют подозрительно много, скажем так, особенностей настройки как самого BootGuard (и его аналога от AMD, который UEFITool NE пока что не поддерживает, но мы работаем над этим), так и вендорских продолжений BG на том(а) DXE. Странности эти - не новость, и о них говорили и Трэммел Хадсон, и Александр Матросов, и многие другие исследователи безопасности UEFI-совместимых прошивок, но воз этот не просто “и ныне там”, он, по ощущениям, с тех пор еще сильнее уехал в сторону жопы. Вот про нее я в этой статье и постараюсь вам рассказать, про то, как делать надо, и как делать не надо, и про то, как делают нынешние IBV, и почему у них получается именно так.

Здравствуй, читатель. За время моего почти десятилетнего отсутствия в мире x86 и UEFI довольно много воды утекло, и то, что раньше считалось интересными, но мало кому нужными настройками прошивки (к примеру, Above 4G Decoding и Resizable BAR) теперь считается фичами первой необходимости (без которых современные видеокарты Nvidia и AMD теряют в производительности, а карты Intel могут и вовсе не работать). При этом прогресс не превратил мощные старые системы в совсем уж полный хлам, и потому есть смысл научить этих старых псов новым трюкам, если это возможно.

Здравствуй, читатель. Перед тобой вторая статья о найденной мной серьезной уязвимости в UEFI-совместимых прошивках на базе платформы Insyde H2O, которую я назвал Hydroph0bia. В первой статье я рассказывал о проблеме "затенения" волатильных переменных NVRAM неволатильными, и о катастрофических последствиях, которые могут наступить при неудачном стечении обстоятельств и неаккуратном программировании критических для безопасности прошивки компонентов. Для правильного понимания этой статьи потребуются знания из первой, поэтому если вдруг она еще не прочитана, рекомендую устранить этот пробел.

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

Здравствуй, читатель. В этой статье я расскажу про найденную мной не так давно серьезную уязвимость в UEFI-совместимых прошивках на базе платформы Insyde H2O, которая присутствует в них примерно с 2012 года и (на большинстве существующих ныне систем) продолжает присутствовать.

Уязвимость эта позволяет надежно (и незаметно для средств мониторинга стандартных переменных UEFI SecureBoot вроде db, KEK и PK) обойти механизм проверки подписей UEFI-драйверов и UEFI-загрузчиков, а для её успешной эксплуатации требуется только возможность записи в UEFI NVRAM (доступная и в Windows, и в Linux после локального повышения привилегий).

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

Здравствуй, читатель. С моих прошлых статей про NVRAM прошло некоторое количество времени (за эти почти 10 лет мало что изменилось, и все эти форматы до сих пор с нами практически без модификаций), а моя работа на одну фруктовую компанию не позволяла мне писать статьи, тесты и посты без одобрения кучей непонятных людей, но теперь эта работа осталась в прошлом, а желание писать так и не пропало. 

Эта статья - практическая реализация этого желания, а поговорим мы в ней о формате Dell DVAR, и немного о декларативном языке для написания парсеров Kaitai Struct, на котором я недавно переписал парсеры всех известных UEFITool NE форматов NVRAM.