Comments 10
Приятно, когда по теме что-то пишут на русском, но для специалиста в статье нет ничего нового и\или интересного, к сожалению.
Не соглашусь. Наибольшую реальную опасность, на мой взгяд, представляют:
— отключенный или неверно настроенный UEFI SecureBoot, который по прежнему никак не могут включить по умолчанию по разным причинам. Т.к. технологию проектировали и в спешке, и при активном противостоянии OSS-сообщества, результат получится «ни жив, ни мертв», т.е. в теории у нас есть безопасная загрузка какая-то, а на практике UEFI CA доверять нельзя совсем (им за 10 лет подписали слишком много уязвимого), работающего механизма отзыва подписей нет (а тот, что есть в виде dbx и dbt страдает от комбинаторного взрыва), работающего механизма отзыва сертификатов нет (все попытки решить вопрос через Audit Mode и Deployment Mode можно считать провалившимися), придумывать что-то новое ни UEFI Forum, ни остальные не торопятся.
— отключенный, или неверно настроенный, или тривиально отключаемый условный BootGuard (т.е. все скопом технологии защиты от модификации прошивки на SPI NOR и\или предотвращения запуска неавторизованного модифицированного кода). Проблема неработоспособности статического корня доверия стоит у MS настолько остро, что они требуют наличия TPM 2.0 для Windows 11, и стремятся всеми силами выкинуть прошивку из цепочки доверия, и я их прекрасно понимаю.
— поистине огромное количество уязвимостей в драйверах, взаимодействующих с переменными NVRAM, вызванное плохим дизайном интерфейса GetVariable и SetVariable.
— практическая незащищенность подавляющего большинства прошивок от DMA-атак, которые за последние ~7 лет превратились из «нужен специалист с ФПГА за 5 килобаксов и куча кастомного кода» в «нужен донгл за 30 баксов и PCILeech с гитхаба».
Самое неприятное, что хочется отметить, это отсутствие и прогресса в безопасности UEFI относительно ее состояния от 2015 года, когда я про нее писал серию статей, и интереса вендоров к этому прогрессу. Годы идут, а мы решаем те же самые проблемы теми же самыми методами, игнорируя десятилетия усилий безопасников и системных программистов, занятых развитием современных ОС. Нельзя сказать, что никто вообще ничего не делает, но все, что делается — делается двумя с половиной вендорами для себя же, а независимого аудита этих «решений» либо не проводится совсем, либо его результаты сразу же засекречиваются по соглашению сторон.
Короче, с точки зрения реальной безопасности прошивок для Wintel PC — «мы в жопе, Баттхед».
наибольшую опасность сегодня представляют уязвимости в режиме SMM и подсистеме Intel ME
Не соглашусь. Наибольшую реальную опасность, на мой взгяд, представляют:
— отключенный или неверно настроенный UEFI SecureBoot, который по прежнему никак не могут включить по умолчанию по разным причинам. Т.к. технологию проектировали и в спешке, и при активном противостоянии OSS-сообщества, результат получится «ни жив, ни мертв», т.е. в теории у нас есть безопасная загрузка какая-то, а на практике UEFI CA доверять нельзя совсем (им за 10 лет подписали слишком много уязвимого), работающего механизма отзыва подписей нет (а тот, что есть в виде dbx и dbt страдает от комбинаторного взрыва), работающего механизма отзыва сертификатов нет (все попытки решить вопрос через Audit Mode и Deployment Mode можно считать провалившимися), придумывать что-то новое ни UEFI Forum, ни остальные не торопятся.
— отключенный, или неверно настроенный, или тривиально отключаемый условный BootGuard (т.е. все скопом технологии защиты от модификации прошивки на SPI NOR и\или предотвращения запуска неавторизованного модифицированного кода). Проблема неработоспособности статического корня доверия стоит у MS настолько остро, что они требуют наличия TPM 2.0 для Windows 11, и стремятся всеми силами выкинуть прошивку из цепочки доверия, и я их прекрасно понимаю.
— поистине огромное количество уязвимостей в драйверах, взаимодействующих с переменными NVRAM, вызванное плохим дизайном интерфейса GetVariable и SetVariable.
— практическая незащищенность подавляющего большинства прошивок от DMA-атак, которые за последние ~7 лет превратились из «нужен специалист с ФПГА за 5 килобаксов и куча кастомного кода» в «нужен донгл за 30 баксов и PCILeech с гитхаба».
Самое неприятное, что хочется отметить, это отсутствие и прогресса в безопасности UEFI относительно ее состояния от 2015 года, когда я про нее писал серию статей, и интереса вендоров к этому прогрессу. Годы идут, а мы решаем те же самые проблемы теми же самыми методами, игнорируя десятилетия усилий безопасников и системных программистов, занятых развитием современных ОС. Нельзя сказать, что никто вообще ничего не делает, но все, что делается — делается двумя с половиной вендорами для себя же, а независимого аудита этих «решений» либо не проводится совсем, либо его результаты сразу же засекречиваются по соглашению сторон.
Короче, с точки зрения реальной безопасности прошивок для Wintel PC — «мы в жопе, Баттхед».
+6
Интересно что мешает сделать переключатель или jumper что бы отключать или включать возможность изменения загрузчика? Зачем надо было городить весь этот огород?
+1
Так раньше ж так и было. Прежде чем прошивать биос надо было замкнуть джампер, иначе не прошивалось. Потом решили, что это слишком скучно :-)
0
Да, но потом пришёл Чих (CIH) или более известно как Чернобыль, ибо активировался 26 апреля, но воз и поныне там. В угоду удобства аппаратную возможность закрытия записи пролюбили в майнстриме. Встречал в "современных" платах, только в формате pc104, но то отдельная тема.
для тех кто не помнит или не знает : https://habr.com/ru/company/timeweb/blog/662740/.
0
Так и сейчас никто не мешает включить BIOS Lock, чтобы получивший админправа зловред не смог прошить мусор из-под ОС. Но защита от перепрошивки к защите от подмены загрузчика имеет слабое отношение.
0
Загрузчик ОС находится на жестком диске, а не в прошивке.
Кроме того, загрузчик периодически обновляется операционной системой (например, в Linux прилетают новые версии GRUB и так далее). Вы и дома-то не захотите каждый месяц перед обновлением ОС лезть перетыкать джамперы, а когда вам это придётся сделать на сотнях и тысячах подшефных ПК на предприятии?
Тем более, защита должна защищать широкий круг пользователей, а не ту ничтожную часть, которая вообще знает, что такое джампер.
Кроме того, загрузчик периодически обновляется операционной системой (например, в Linux прилетают новые версии GRUB и так далее). Вы и дома-то не захотите каждый месяц перед обновлением ОС лезть перетыкать джамперы, а когда вам это придётся сделать на сотнях и тысячах подшефных ПК на предприятии?
Тем более, защита должна защищать широкий круг пользователей, а не ту ничтожную часть, которая вообще знает, что такое джампер.
+1
Не надо путать тёплое с мягким. Ничего не мешает делать механическую защиту прошивки. А вот уже загрузчик можно проверять с помощью обычных публичных ключей, которые предварительно были записаны в прошивки и могут быть изменены только с помощью «перемычки».
загрузчик периодически обновляется операционной системойвот когда ему это понадобиться пусть явно просит подписать свой загрузчик моими ключами или просит установить публичный ключ операционной системы в прошивку.
0
Sign up to leave a comment.
Как буткиты внедряются в современные прошивки и чем UEFI отличается от Legacy BIOS