Комментарии 24
Это ж надо, — сколько всяких умных инжинеров работало, чтобы родить систему UEFI.
А из-за повальной кривой реализации получается, что и защиты толком нет, и пользователям геморой.
Хотелось, как лучше, а получилось, как всегда.
А из-за повальной кривой реализации получается, что и защиты толком нет, и пользователям геморой.
Хотелось, как лучше, а получилось, как всегда.
Ситуация такая в основном потому, что SecureBoot по прежнему очень редко используется, от этого он недостаточно протестирован и потому кривые реализации продолжают быть кривыми — просто никто не знает о том, что они кривые. При этом SecureBoot — единственная нормальная защита от вредоносных OROMов и загрузчиков, и без него на любой системе можно загрузить UEFI Shell и натворить кучу неприятных дел.
Вместо распространения вестей о том, что SecureBoot — это злодейское изобретение MS для ограничения свободы пользователя, нужно распространять знания о том, как им пользоваться правильно, как сгенерировать свои собственные PK и KEK, как удалить предустановленные, как подписать собственный загручик и так далее. Я напишу об этом статью после окончания этого цикла.
Вместо распространения вестей о том, что SecureBoot — это злодейское изобретение MS для ограничения свободы пользователя, нужно распространять знания о том, как им пользоваться правильно, как сгенерировать свои собственные PK и KEK, как удалить предустановленные, как подписать собственный загручик и так далее. Я напишу об этом статью после окончания этого цикла.
Еще помню у какого-то вендора ад с открытым хранением ключей в Setup.
Их потом intel в блек-лист занесли (ключи, а не вендора ;) ).
Еще не затронуты атаки на перепрошивку. Там тоже много забавных buffer overflow было.
Их потом intel в блек-лист занесли (ключи, а не вендора ;) ).
Еще не затронуты атаки на перепрошивку. Там тоже много забавных buffer overflow было.
Пропустил, каюсь. Их исправили еще пару лет назад и я давно про них не слышал, вот и забыл.
Для тех, кто не в курсе: суть атаки в том, что обновление и PK и KEK, и db с dbx возможно не только из BIOS Setup, но и из ОС, и в правильной реализации для обновления PK и KEK нужен текущий PKpriv, а для обновления db и dbx — KEKpriv. На некоторых старых реализациях при проверке подписи этих обновленных ключей можно было организовать переполнение буфера ии получить доступ к NVRAM, а дальше просто заменить или удалить PK. Проблему нашли и исправили достаточно быстро, еще в 2012 году, и с тех пор о ней больше не слышно. Прошу прощения, что я про нее забыл.
Для тех, кто не в курсе: суть атаки в том, что обновление и PK и KEK, и db с dbx возможно не только из BIOS Setup, но и из ОС, и в правильной реализации для обновления PK и KEK нужен текущий PKpriv, а для обновления db и dbx — KEKpriv. На некоторых старых реализациях при проверке подписи этих обновленных ключей можно было организовать переполнение буфера ии получить доступ к NVRAM, а дальше просто заменить или удалить PK. Проблему нашли и исправили достаточно быстро, еще в 2012 году, и с тех пор о ней больше не слышно. Прошу прощения, что я про нее забыл.
Спасибо за цикл статей.
А насколько лучше дела обстоят у coreboot и libreboot по сравнению со стандартными прошивками?
И в одной из прошлых статей вы назвали x86 неподходящей платформой для параноика — а какая из ныне существующих подходящая? =)
А насколько лучше дела обстоят у coreboot и libreboot по сравнению со стандартными прошивками?
И в одной из прошлых статей вы назвали x86 неподходящей платформой для параноика — а какая из ныне существующих подходящая? =)
Пожалуйста, спасибо, что читаете.
Насколько — не могу сказать точно, мало опыта использования coreboot, но заведомо меньше, т.к. кодовая база намного компактнее и никто не пытается добавить в прошивку все, до чего руки дотянулись и компилятор смог собрать. Будет время — попробую разобраться получше.
Подходящая платформа для параноика сильно зависит от степени паранойи, кому-то достаточно ARM без TrustZone (хотя их таких пойди еще найди теперь), кому-то можно посоветовать OpenRISC (только вот всего 2,5 процессора ровно одной маленькой компании — это очень грустно), кто-то может посмотреть в сторону отечественных решений или китайских MIPSов (это если вам свои бэкдоры милее чужих).
Насколько — не могу сказать точно, мало опыта использования coreboot, но заведомо меньше, т.к. кодовая база намного компактнее и никто не пытается добавить в прошивку все, до чего руки дотянулись и компилятор смог собрать. Будет время — попробую разобраться получше.
Подходящая платформа для параноика сильно зависит от степени паранойи, кому-то достаточно ARM без TrustZone (хотя их таких пойди еще найди теперь), кому-то можно посоветовать OpenRISC (только вот всего 2,5 процессора ровно одной маленькой компании — это очень грустно), кто-то может посмотреть в сторону отечественных решений или китайских MIPSов (это если вам свои бэкдоры милее чужих).
Я все бредил собрать/купить себе ноут на arm или mips, а сейчас смотрю — прошивка платы тоже непонятно как собрана, на самих платах физической защиты нет, ядра на процессор в большинстве своем идут с бинарными блобами и древних версий, на gpu вообще дров нет…
Свободные novena — тоже замучаешься компилировать все под нее, taurinus — очень спорная штука…
Вот и получается, что как ни крути, простому пользователю проще взять себе обычное железо и не переживать почем зря. В крайнем случае получится поставить corebot, но это будут делать совсем уже гики…
Грустно это все…
Хотя те же мобильники с точки зрения безопасности гораздо большая брешь =)
Свободные novena — тоже замучаешься компилировать все под нее, taurinus — очень спорная штука…
Вот и получается, что как ни крути, простому пользователю проще взять себе обычное железо и не переживать почем зря. В крайнем случае получится поставить corebot, но это будут делать совсем уже гики…
Грустно это все…
Хотя те же мобильники с точки зрения безопасности гораздо большая брешь =)
Про корбут отвечу. Это вещь в себе, т.е. можно сказать, что есть UEFI, есть Legacy BIOS и есть coreboot. Заранее скажу, что payload-ы я рассматриваю только со стороны Seabios-а (CSM-а, если смотреть как на UEFI).
Исходные коды вполне чистые, особо косячных мест нет, возможно, если дописать своего кода побольше, то удастся испортить cbmem консоль. Защиты от перезаписи нет, видать из идеологических соображений, т.е. перезаписать содержимое флешки может любой юзер, которому в руки попался flashrom. Но тут каждый кузнец своего счастья, добавить защиту PR регистров в него можно особо не гемороясь, благо функционал работы с SPI есть готовый, правда прийдется ещё и #WP ножку помучать, но тут уж извините, либо сами делайте плату, либо дорабатывайте готовую. SMI режим не используется (за блобы ничего не скажу) из тех-же идеологических соображений наверное. Поддержка ACPI… ну… всё плохо для любителей хакинтошей и ценителей «всегда последняя версия стандарта» — 2.0 оно вполне может (если опятьже для вашей платы оные asl-ки написаны, либо вы их напишете), в ограниченном формате, чтобы винда запуститься смогла =), зато с безопасностью проще. Хранение настроек — если не хотите, оно вообще может их нигде не хранить, если хотите — пожалуйста, всё в классическом понимании — CMOS RAM, правда настройки не те, что ожидаются (типа частоты памяти, множителей, приоритета адаптеров), а более отладочные (скорость ком-порта, и т.д.), и опять-же, если для вашей платы оная поддержка сделана.
SeaBios — вполне вещь в себе, с безопасностью — как у обычного старого Legacy BIOS, грузится отовсюду, откуда может, OPROM-ы запускает все, что найдет (если при сборке ей об этом сказали). Чистота кода — всяко чище, чем любое творение от IBV, выпущенное после эпохи Pentium1.
Кто хочет допом к этому поиметь геммороя — может собрать payload-ом UDK и получить что-то вроде UEFI в виде почти чистого TianoCore. Но что-то особого кол-ва желающих я не замечал.
Исходные коды вполне чистые, особо косячных мест нет, возможно, если дописать своего кода побольше, то удастся испортить cbmem консоль. Защиты от перезаписи нет, видать из идеологических соображений, т.е. перезаписать содержимое флешки может любой юзер, которому в руки попался flashrom. Но тут каждый кузнец своего счастья, добавить защиту PR регистров в него можно особо не гемороясь, благо функционал работы с SPI есть готовый, правда прийдется ещё и #WP ножку помучать, но тут уж извините, либо сами делайте плату, либо дорабатывайте готовую. SMI режим не используется (за блобы ничего не скажу) из тех-же идеологических соображений наверное. Поддержка ACPI… ну… всё плохо для любителей хакинтошей и ценителей «всегда последняя версия стандарта» — 2.0 оно вполне может (если опятьже для вашей платы оные asl-ки написаны, либо вы их напишете), в ограниченном формате, чтобы винда запуститься смогла =), зато с безопасностью проще. Хранение настроек — если не хотите, оно вообще может их нигде не хранить, если хотите — пожалуйста, всё в классическом понимании — CMOS RAM, правда настройки не те, что ожидаются (типа частоты памяти, множителей, приоритета адаптеров), а более отладочные (скорость ком-порта, и т.д.), и опять-же, если для вашей платы оная поддержка сделана.
SeaBios — вполне вещь в себе, с безопасностью — как у обычного старого Legacy BIOS, грузится отовсюду, откуда может, OPROM-ы запускает все, что найдет (если при сборке ей об этом сказали). Чистота кода — всяко чище, чем любое творение от IBV, выпущенное после эпохи Pentium1.
Кто хочет допом к этому поиметь геммороя — может собрать payload-ом UDK и получить что-то вроде UEFI в виде почти чистого TianoCore. Но что-то особого кол-ва желающих я не замечал.
Спасибо,
я от разработки железа далек, рассматриваю чисто со стороны любительского опыта смены прошивки.
я от разработки железа далек, рассматриваю чисто со стороны любительского опыта смены прошивки.
Открываете список плат, которые оный корбут умеет. Ищите по ebay/авито/локальнаябарахолка, что там в наличии из желаемого (как вариант для заинтересованного параноика — T60 с интегрированной графикой, тогда наура взлетит libreboot). Также докупаем программатор за 4уе на всякий случай. В результате имеем железку, большинство кода которой можно спокойно изучить и поправить, не используя сильное колдунство вида ida/radare2
Лучше тогда хромбуки
Осталось упомянуть, что SecureBoot не совместим и не должен быть включен совместно с CSM
Купил в этом году материнскую плату – в UEFI включены Secure Boot и CSM одновременно, отключить последний нельзя (при перезагрузке настройка включается опять).
Попробуйте переключить все опции Launch… Option ROM в UEFI Only, перезагрузиться и отключить CSM — должно сработать. Обычно CSM не дает отключить себя если VBIOS загружен, но нармальные реализации UEFI предупреждают об этом сообщением при попытке отключить CSM.
Я вот главного не могу понять — предположим, я купил комп с этой хренью на борту. Могу я (теоретически) установить собственный PK-ключ, решить кому и почему я доверяю, прописать их ключи в KEK, db, а если потребуется, то и в dbx? Подписать собственный загрузчик? Если это возможно теоретически, то как с этим дело обстоит на практике? Требуется ли этот функционал каким-либо стандартом/спецификацией или это добрая воля производителей и эта возможность может быть в любой момент заблокирована в новых продуктах?
Или это принципиально невозможно? Если так, то это начинает сильно напоминать вендор-лок.
Или это принципиально невозможно? Если так, то это начинает сильно напоминать вендор-лок.
Это возможно и теоритически, и практически, но некоторые производители сознательно прячут эти настройки от пользователя, не желая описывать их в документации, либо специально блокируя возможность смены ключей, как это сделано на смартфонах и планшетах Microsoft.
Я постараюсь рассказать подробнее о настройке SecureBoot в отдельно посте, прошу только подождать немного.
Я постараюсь рассказать подробнее о настройке SecureBoot в отдельно посте, прошу только подождать немного.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О безопасности UEFI, часть пятая