Pull to refresh

Comments 28

Полный восторг. Хабр — торт. Редко попадается такой уровень публикаций) спасибо.
Очень круто. Жалко только, что для такой достаточно полезной вещи приходится столько приседать, вместо того, чтобы щёлкнуть чекбокс при инсталляции.
UFO just landed and posted this here
Если говорить об уязвимостях в прошивке и железе, оставленных из-за некомпетентности разработчиков и производителей, то здесь спасения нет нигде. Ни прошивки с открытым исходным кодом, ни железо собственного производства от них не застрахованы. Можно только полагаться на репутацию конкретного производителя и следить за новостями об атаках на данное устройство.

Если вы имеете в виду намеренно оставленные закладки, то здесь нужно учесть область применения Secure Boot и взвесить важность вашей информации против стоимости атаки на неё. Эффективно используя Secure Boot, вы ограничиваете круг противников (adversary) до тех, кто способен использовать эти закладки, значительно увеличивая стоимость атаки. Как мне кажется, для ноутбука с личными данными такой защиты достаточно. Для информации, вызывающей острый интерес иностранных служб разведки, наверное, нет.

У представленных на рынке устройств есть свой предел по обеспечению информационной безопасности. Правильное использование Secure Boot позволяет максимально приблизиться к этому пределу для конкретного устройства. Если в устройстве реализован Secure Boot, то есть смысл его использовать.
UFO just landed and posted this here
> имея физ доступ секуребут вообще ни разу не проблема, даже на элементарном уровне, без реверса и хакинга: покупаем такую же железку, перетыкаем винт с модифицированным загрузчиком и всё

Пару простых советов по защите от физического доступа я описал в статье. Сможете воспроизвести все пятна, царапины и наклейки на моём ноутбуке так, чтобы я не заметил подмены?

> Ещё раз: в чём польза простому юзеру от секуребута?

Пользователю, который не шифрует свои данные, пользы от него нет. Для себя я пользу нашёл — в качестве защиты от атаки Evil Maid. Если вы считаете, что в таком качестве он непригоден, объясните. Остальное офтопик.
UFO just landed and posted this here
Спасибо огромное за статью, я как раз недавно зашифровал все свои диски которые только были и у меня остался нерешенным вопрос с загрузчиком, сегодня наконец буду спать спокойнее.

Насчет доверия к uefi, есть вообще какие либо альтернативы? Допустим я могу прошить свой чип с биосом.
CoreBoot и его полностью обезблобленный форк LibreBoot. Но поддерживаемое железо вас расстроит. Плюс если вы не хотите бинарных модулей, то всё от интела старше Core 2 Duo вам не подойдет. С амд чутка лучше, но всёравно, как появляется PSP так исчезает agesa в исходниках. SecureBoot там нет, но в случае использования только линукса он становится ненужным — можно грузить ядро напрямую (FILO) либо всунуть его в образ прошивки.
Гуглите open source uefi
https://www.coreboot.org/
http://www.tianocore.org/
https://libreboot.org/
Отличная статья, спасибо.

Поправлю немного по примечаниям:
4. Выбрать загрузочное устройство в  Windows 8 и Windows 10 очень просто, даже не имея пароля. На стартовом экране есть кнопка Power, которая открывает меню с Power off/Standby/Restart. Если нажать на Restart удерживая Shift, вместо перезагрузки произойдет переход в меню Troubleshooting, откуда можно перейти сначала на Advanced Settings, а затем и на Startup Settigs, где и выбрать следующее загрузочное устройство. Пишу по памяти и не имею сейчас доступа к машине с Windows, но когда я пробовал вышеописанное в последний раз пару месяцев назад — работало.
5. Лучше не создавать больше одного ESP (и не создавать ESP меньше 200 Мб, ограничение не жесткое, но некоторым старым загрузчикам не нравится), а просто сложить все загрузчики на один раздел. Efibootmgr действительно лучше не пользоваться, а вот UEFI Shell намного чаще приходится загружать с внешнего носителя, т.к. встраивать его себе в прошивку — потенциальная проблема безопасности, и потому не очень рекомендуется.

Нужно бежать на работу, потом допишу еще пару замечаний, когда смогу прочитать статью вдумчиво, а не на бегу.
Спасибо за замечания.

4. Я об этом способе и говорю, пароль не нужен. У меня Windows передаёт команду на загрузку устройства UEFI, а в нём загрузка с USB отключена, поэтому загрузка не срабатывает. Не исключено, что раньше Windows делала это как-то по-другому, или моя прошивка не имеет такой уязвимости. Из вашей же статьи о нём и узнал.

5. Откуда можно стянуть UEFI Shell? Добавил бы ссылку в статью. В гугле находятся бинарники неизвестного происхождения. В вики Ubuntu вообще написано: «Если вы ставили Ubuntu на чистый диск, а в прошивке нет встроенного UEFI shell, то его можно доставить руками. Сам бинарный файл легко находится через любой поисковик».
Откуда можно стянуть UEFI Shell?

Я пользуюсь шеллом из состава Tianocore EDK2
Для арча есть пакетик в AUR'e, для остальных ОСей не знаю, к сожалению, но можно собрать ручками по аналогии. Либо взять бинарную сборку из репы.
Технология Secure Boot нацелена на предотвращение исполнения недоверенного кода при загрузке операционной системы

Не, она нацелена на поддержание vendor lock-in от Mi©ro$oft

Кстати, а что делать если система перестанет загружаться по какой-то причине?
Чрут с live cd уже не сделать…
Временно отключить Secure Boot до исправления проблемы. Если потребуется изменить ключи, то снова перевести в Setup Mode.

трюк с /tmp/cmdline вполне можно сделать и без временного файла:


CMDLINE="quiet nosplash"

objcopy \
  --add-section .cmdline=<(echo $CMDLINE) --change-section-vma .cmdline=0x30000
  # etc

Хотя ничего критичного нет, всё равно выполняется на доверенной системе.

Статья почти слово в слово повторяет мою запись в личной wiki. Мне порой кажется, что если я что-то подобное опубликую, то в меня полетит критика в роде "капитан очевидность" или "задрот".


У меня вопрос к следующей фразе:


Однако отсутствие верификации initramfs позволяет встроить в него вредоносный код, имея доступ на запись в ESP. Teddy Reed предлагает компилировать ядро, встраивая в него initramfs.

Как это может быть, если initramfs находится на зашифрованном разделе (а не на ESP), а grub при загрузке сначала запросит пароль перед тем как считать initramfs и ядро с зашифрованного диска. Зачем нужна морока со сборкой и подписью своего ядра?


На ESP в моём случае находится лишь только grubx64.efi

В сноске 2 как раз правильное решение используется.


Теоретически можно исправить, установив пароль, встроив grub.cfg в образ GRUB с помощью grub-mkstandalone и установив в grub.cfg prefix на невалидный путь, чтобы GRUB не мог найти второй grub.cfg на диске. Но опять же требуется подписывать образ самостоятельно.
Я бы не назвал какое-либо из решений единственно правильным, они скорее всего оба работают. Описанное мной кажется мне проще и надёжнее. Не факт, что таким образом закроются все дыры GRUB.
У вас GRUB работает в Secure Boot с шифрованием /boot? Если initramfs находится в зашифрованном разделе, а у GRUB заблокированы консоль и загрузка конфигурации из файла, в нём нельзя изменить передаваемые ядру параметры при загрузке, то дополнительно защищать initramfs не нужно. В противном случае его можно подменить.

UEFI secure boot кстати вполне спокойно работает на MBR (не могу точно сказать насколько это соответствует стандарту, давно проблему решал). Только необходимо osprober пофиксить https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817023

Не оставляйте устройство включённым без присмотра. Устройство в ждущем режиме (suspend to RAM) содержит в RAM расшифрованные данные и мастер-ключи от криптоконтейнеров

А есть какая-то информация о способах получить доступ к этой памяти?
Вот стоит включенный ноут, с заставкой и требует пароль (вход уже выполнен, так что в памяти нешифрованные данные). Каким образом можно получить доступ к данным в оперативке, даже при наличии физического доступа? Память ведь энергозависима, да и к работающей подключиться и что-то считать сторонним устройством скорее всего не выйдет.
Cold boot attack
https://ru.wikipedia.org/wiki/Cold_boot_attack
Статья не вызывает доверия. Большая часть ссылок в ней уже мертва, и датируются они 2002-2011гг. Чуть больше информации в англоязычной, но ссылки… то же самое.
https://en.wikipedia.org/wiki/Cold_boot_attack
Но в целом суть я понял, спасибо.
Видимо, кто-то не понял. Я говорю про статью в википедии (рус.) https://ru.wikipedia.org/wiki/Cold_boot_attack
Я правильно понимаю что при этом сертификаты MS остаются, и позволяют запустить подписанные им программы? например shim (что как я понял из статьи та еще дыра).
А правильным будет, после проделанного в статье, удалить сертификаты MS и Canonical?
Возможно ли, и как?

И вопрос 2. шифрование на уровне всего диска делает невозможным прочитать данные?
если это так то зачем мазать лаком винт, что бы уберечься от подмены файлов, винт же будет не читаемым без пароля?
если нет то смысл вклюать шифрование?
Я правильно понимаю что при этом сертификаты MS остаются, и позволяют запустить подписанные им программы? например shim (что как я понял из статьи та еще дыра).

Сертификатов MS не будет, если их не добавлять специально. В этой статье рассматривается их добавление в db, но делать это необязательно. Насколько это безопасно — сразу сказать не могу, надо подумать.

если это так то зачем мазать лаком винт, что бы уберечься от подмены файлов, винт же будет не читаемым без пароля?

Мазать не винчестер, а крепёж на ноутбуке или системном блоке, чтобы факт вскрытия был заметен. Прочитать данные невозможно, но при физическом доступе к материнской плате можно сбросить настройки Secure Boot или банально заложить подслушивающее устройство.
Sign up to leave a comment.

Articles