Comments 11
BootGuard нужен для того, чтобы атакующий, получивший доступ на запись NOR flash, на котором хранится прошивка, не мог внести в нее неавторизованные изменения
Так может не надо давать атакующему доступ на запись NOR Flash? Сделать изменение прошивки биоса исключительной ситуацией, требующей уведомления пользователя и физического подтверждения - а не рутинной операцией, которая незаметно происходит каждую неделю и которую может запустить кто угодно из любой точки Земли?
Не знаю как сейчас сделано в UEFI,но есть одна вещь: называется таблица (фактически микрокод) DMI .И эта таблица записывается в Биос - при первой инициализации внешней платы.И была одна контора - авреал (3 д звук) , из за кривых таблиц на их карточках до хрена у народа (в основном матери VIA) оказалось "кирпичами" .Так что придется делать достаточно сложную микросхему Флэш памяти - которая может не давать просто так записывать данные в защищённую область без цифровой подписи.Но многие вендоров кстати так уже и делают - есть защищённые Биосы которым вирусы не страшны,а в случае проблем с загрузкой могут переключиться на альтернативную версию прошивки.
И эта таблица записывается в Биос - при первой инициализации внешней платы.
И я про то же - нехрен давать кому угодно возможность записи в биос. Втыкаемая в матплату карточка должна работать с этой матплатой, а не конфигурировать ее по своим кривым хотелкам. Это примерно как если бы пассажир, садясь в такси, первым делом втыкал ноутбук в разъем OBD и настраивал режим работы двигателя.
Механизмов защиты уже придумано тьма. Вопрос в их корректной конфигурации и применении. Николай как раз про это и написал. Те же Protected Range, к примеру, я ещё ни разу не встречал настроенными...по крайней мере на AMI (понятно, что за все не могу говорить, но на своём опыте не видел). Ну и полностью закрыть доступ на запись во Flash (даже хотя бы в runtime фазе) тоже вряд ли хорошее решение, ибо доступ на запись в nvram, например, нередко в ОС нужен.
Я видел работоспособные Protected Ranges на машинах Dell/Alienware, использовавших AMI AptioV, но и они там были настроены криво (потому что разработчики не в курсе, что PRRы нужно выравнивать с обеих сторон по границе в 16 (иногда 64) кб, а у них на границе было как раз начало тома DXE, лежавшего сразу за томом с NVRAM).
Первое: доступ этот может быть физическим, и затруднить его в таком случае довольно непросто: придется закапывать дорожки внутрь платы, специальным образом разводить SPI-чип (потому что конденсаторы фильтровочные теперь не поставить, т.к. они по определению будут на поверхности, либо придется в плату закапывать и их, а это нестандартный процесс, который кратно дороже выйдет), лишаться разъема In-System Programming (т.е. заранее напаивать уже прошитые SPI-чипы в корпусе TFBGA24). Это все - обычные инженерные задачи ("ну надо так надо"), но они заметно удорожают плату, и потому переживут этап BOM cost optimization в исключительных случаях (игровые консоли, продающиеся в убыток, с надеждой вернуть убыток за счет лицензионных игр, например).
Второе: современный x86 ПК хранит на SPI-чипе не только условный BIOS, но и множество других прошивок, которым необходимо и читать с него данные, и писать их, в том числе во время работы системы. Раньше это решалось подключением отдельного чипа CMOS SRAM, но таковые либо малоёмкие (если недорогие), либо дорогие (если хоть сколько-нибудь емкие), да и доступ к ним все равно происходит через CPU IO-порты, т.е. доступен любому атакующему с правами рута (а локальное повышение привилегий в любой популярной ОС большой тройки - практически решенный вопрос, десяток новых CVE каждый месяц не даст соврать). Более того, наличие UEFI NVRAM подразумевает возможность записи новых переменных во время работы ОС, поэтому какая-то часть SPI-чипа все равно должна оставаться R/W.
Третье: это все реально можно сделать лучше, поставить два чипа, отдав второй чисто под R/W-регионы, и закрыв первый от записи физическим переключателем, и это уже делается вполне на дорогом промышленно оборудовании, обслуживаемом профессионалами с высокими зарплатами, но на домашней электронике для простого пользователя это все приведет исключительно к убыткам, перегрузке технической поддержки, и т.п. Пользователь обычный чаще всего вообще не в курсе, что у него есть какая-то прошивка, а там в прошивке тем временем 30+ мегабайт кода на С, который просто невозможно "сразу сделать хорошо" при текущих способах разработки системного ПО. Если не научиться обновлять эту самую прошивку незаметно для пользователя каждую неделю (да хотя бы раз в пару месяцев, не до жиру), то очень скоро почти все ваши системы на руках у пользователей будут иметь известные незакрытые уязвимости, через которые их будут грызть черви, а вы ничего с этим сделать не сможете.
В общем, лучше можно сделать гарантировано, и способы есть для этого известные, и примеры, но пока производителя не начнут бить палкой либо сами пользователи (через потерю репутации, но там зачастую терять уже давно нечего), либо государство (через регулирование и штрафы) - лучше ничего не будет, потому что "и так берут".
а бутгард поддерживается во всех биосах или только в некоторых?
Только в некоторых, в основном на ноутбуках, AIO, серверах и т.п. системах, которые поставляются в сборе, и для которых для производителя есть смысл защищать прошивку (в том числе и от пользователя).
Процессоры Intel поддерживают BootGuard начиная с Haswell/Broadwell, но фьюзы (одноразовые электрически-пережигаемые дорожки) у Intel находятся в чипсете, а не в процессоре (ну, кроме случаев SoC, когда чипсет и процессор установлены под одной крышкой), и потому для откручивания BG достаточно замены чипсета и сброс конфигурации CSME и FIT при помощи Flash Image Tool. У AMD их аналог BootGuard поддерживается, ЕМНИП, с Zen 1 (может быть чуть раньше даже, но на Merlin Falcon PSP уже был, а BG - еще нет, вроде бы), и фьюзы находятся в процессоре, и для удаления BG придется менять именно его.
А как обстоят дела с этим у современных HP и Dell? Они всегда были мастера сделать что-то своё
HP на современных машинах использует BootGuard для защиты SEC и PEI, как обычно, а для всего остального (в том числе NVRAM, внезапно, отчего они умеют задорно окирпичиваться при попытке Windows Update доставить обновления переменных SecureBoot) они придумали SureStart.
Dell, насколько я знаю, использует те же решения IBV, что и все остальные.
Пара слов о состоянии BootGuard в UEFI-совместимых прошивках