Super UEFIinSecureBoot Disk — запуск любых ОС и .efi-файлов с флешки без отключения UEFI Secure Boot

Можно воспользоваться штатными возможностями GRUB2 или iPXE.

Те скрипты, которые включены в состав образа — просто для примера работоспособности диска. Это не мультизагрузочный диск, это основа для него.

SeaBIOS — BIOS, так что совместимо.

Этот диск бы просто загрузился.

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

Благодарю за ответ. Если я правильно понял, этот образ приносит пользу только UEFI-компам где есть проблемы с Secureboot?

Забавно. Половина отписавшихся даже не знают зачем нужен Secure Boot и вместо этого пишут что-то о покушении на их анальную девственность.

Shim без нарушений. Он использует EFI сервис для загрузки модулей. А вот grub2 с нарушением. У него собственный код загрузки efi модулей. А еще он умеет грузить ядра, не являющиеся efi модулями. Вобщем полный ахтунг, все загружает, нихера не проверяет.

Secure Boot не дырявый и нужный, хорошо делает то, для чего предназначался — защита от буткитов, от незаметной подмены загрузчика.

Secure Boot не ограничивает пользователя: на любых материнских платах можно добавить любые сертификаты, можно удалить сертификаты Microsoft, если хочется, можно сгенерировать свои ключи платформы и полностью им управлять.

Этот диск предназначен, в первую очередь, для случаев, когда Secure Boot невозможно или неудобно отключать (например, из-за пароля для UEFI Setup, который забыли). Если воспользоваться обычным shim и grub, то в shim придется добавлять сертификаты или хеши всех файлов .efi, которые планируется загружать, что очень неудобно.

Требование Microsoft к подписываемым загрузчикам — чтобы они не могли загружать любые файлы тихо, без подтверждения со стороны пользователя. Shim соответствует этому критерию.

загрузчик у нас редхата, подписан микрософтом, но не проверяет, что загрузится дальше

Он проверяет. Если через shim пытаются загрузить efi-файл, сертификата подписи которого нет в UEFI db или внутри самого shim (в случае диска — это preloader, который уже дальше загружает grub), то он запускает также подписанный MokManager.efi, который предлагает добавить сертификат файлов в базу разрешенных.

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

Скорее компам, где установлен пароль на UEFI Setup, или для случаев, когда нужно загрузиться с флешки вот прямо здесь и сейчас. Вопрос удобства, скорее.

Бедняга, навечно лишить себя процессоров пристойной производительности…

а где тот коммент, после которого «эта прелесть» превращается в тыкву? был же вроде. помню же, там говорилось, что потом нужно нафиг сбрасывать сертификаты в бивасе, т.к. «эта прелесть» его туда прописывает.

и чего я не могу залогиненным ответить?

Secure Boot не ограничивает пользователя: на любых материнских платах можно добавить любые сертификаты, можно удалить сертификаты Microsoft, если хочется, можно сгенерировать свои ключи платформы и полностью им управлять.

Вот если бы так, то на просторах инета не было бы тонн форумов «железка_name не даёт загрузить/не принимает ключи/окирпичилась». К счастью таких железок у меня нет, но ведь и дыма без огня не бывает.

защита от буткитов

Достаточно надёжной защиты от буткитов не существует и этот загрузчик тому подтверждение. Да и сами буткиты настолько редкие звери, что я ни об одном не слышал. Опять же в быту, я не знаю чем там профи ломают чужие серверы.

Хотя... Может быть надёжная защита от буткитов. Надо писать провереный загрузчик, firmware и ядро/initrd на диск с аппаратной защитой от записи и грузиться с него. Обновлять соответственно с провереной машины вручную.

Я и так могу запускать что угодно через uefi shell. Нахрена козе баян? Одни кликбейты, уже в полное гавно скатился ресурс

Какая же у вас каша в голове боже ты мой. Защита от буткитов. Подписал pe серт щашил в фирмварь вот и все защита, если подпись не прошла тупо не грузим какаху

если у тебя процессор серии Intel Coffee Lake не можешь модифицировать прошивку bios. Части прошивки вообще зашифрованы и расшифровываются и работают на отдельном процессоре (Intel Me, PSP у AMD).

Чем CoffeLake в этом плане отличается от предыдущих поколений? Если вы имеете в виду, что в каком-нибудь Sandy Bridge прошивка ME была не зашифрована, то это не так (насколько мне известно). Поэтому просьба пояснить, почему вы сделали акцент именно на CL

Ну и это совершенно не означает «не можешь модифицировать прошивку BIOS». Модифицировать регион BIOS (и встроить туда вредоносный драйвер) можно полностью. ME живёт в отдельном регионе.

на любых материнских платах можно добавить любые сертификаты

К сожалению, в среде пользователей Linux кем-то намеренно культивируется (по глупости или со злым умыслом) миф о том, что SB нужен только для того, чтобы Microsoft запретила ставить Linux на ноутбуки Surface.

Это гораздо проще, чем сесть и реально разобраться, почему SecureBoot является чуть ли не единственной защитой от вредоносных OROM-омв, и в том, как его грамотно настроить.

Кому надо, шифрует диски и ставит пароль на EFI.

Вы упускаете то, что кто-то незашифрованный должен принять у вас пароль шифрования и расшифровать диск. Этот кто-то - загрузчик. Как вы будете защищаться от подмены загрузчика?

Именно этим занимается SecureBoot - проверяет подлинность внешних, по отношению к UEFI BIOS, компонентов (драйверов, загрузчиков и т.д.)

Если же нужно пойти глубже и зашититься от изменения самой прошивки, то существует Intel Boot Guard, конфигурация которого может быть раз и навсегда записана во фьюзы чипсета без какой-либо возможности её изменить. После этого обновлять прошивку UEFI на этой системе сможет только обладатель приватной части корневого ключа (т.е. тот, кто включил Boot Guard).

Естественно, вы не найдёте этого в «материнской плате асус для геймеров», потому что пользователи начнут жутко выть, обнаружив, что никаким образом, даже аппаратным программатором, нельзя прошить прошивку, не подписанную вендором.

Чем CoffeLake в этом плане отличается от предыдущих поколений? Если вы имеете в виду, что в каком-нибудь Sandy Bridge прошивка ME была не зашифрована, то это не так (насколько мне известно). Поэтому просьба пояснить, почему вы сделали акцент именно на CL

Что прошивку вообще (а не только ME) не получится самому произвольно модифицировать. Ее подпись проверяется CPU. Boot Guard о ком ты сам же и говоришь.

К сожалению, в среде пользователей Linux кем-то намеренно культивируется (по глупости или со злым умыслом) миф о том, что SB нужен только для того, чтобы Microsoft запретила ставить Linux на ноутбуки Surface.

Но ведь на практике именно для этого и нужна на Surface.

Есть очень простой тест на чистоту помыслов, когда тебя какие-то дяди хотят облагодетельствовать. Это вопрос, можно ли отказаться от счастья быть облагодетельствованным? И если нет - тебе лапшу на уши вешают под слова о том как тебе будет хорошо. Пока что на x86-х компах обычно можно отказаться от защиты с помощью SB. Но сделано это все в такой манере, что в любой момент очень легко может стать невозможным. И вот на ARM - это уже требование производителя, чтобы пользователь не смог поставить что хочет.

Intel Boot Guard

Не нашел в интернете, она при запуске проверяет только прошивку или еще и настройки? Если да, то для ентерпрайза самое то.

Только вот мало кто со мной станет спорить, что неотключаемый Secure Boot - абсолютное зло, которое заставляет для запуска нормальной ОС использовать такие костыли, как сабж.

К тому же, конфигурация UEFI с Secure Boot слетает от простого доставания CMOS батарейки, что означает полное отсутствие защиты от отвертки.

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

Я конечно может чего-то недопонял, но разве приватный ключ майкрософт для подписи не был слит ещё в 2016?

подписан ключом Microsoft

Поржал.

Ну, отлично. Подписываем каку открытым или краденым ключом (кажется пачка ключей секюриБут уже утекала), а буткит подгружаем модулем на более позднем этапе.

Вероятно, вы путаете с Golden Key-загрузчиком Windows, который позволяет задавать произвольные параметры запуска Windows, например, включать test signing, даже на ARM. Ключи не утекали.

Спасибо за проделанную работу, утилита очень полезная, надо переделать свои загрузочные флешки на такой вариант.

Узнал про glim и решил посмотреть, может придумали способ загрузки любых образов, а оказалось что это просто набор конфигов для grub под конкретный список дистрибутивов, у которых в initrd которых вшита утилита для поиска и монтирования iso-образа на внешнем носителе. Для некоторых старых образов использовал передачу загрузки в grub4dos, который умел немного больше, чем grub2.

Только вот вопрос, если при первой загрузке MokManager прописывает нужный сертификат в UEFI, то не выйдет ли так, что какой-нибудь зловред сможет подпихнуть свой загрузчик (или гипервизор), подписанный сертификатом из этого загрузчика, в систему и загрузиться нормально, либо надо каждый раз будет выбирать сертификат при загрузке?

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

Ну об этом и речь, теперь кто угодно может вписаться в загрузку. Но мы не будем писать зловредов, только добропользов!

А может просто надо подписать загрузчик своим ключем и скормить свой ключ UEFI, чем заниматься вот этой вот хернёй?

Помимо glim, есть ещё https://github.com/aguslr/multibootusb

Только вот вопрос, если при первой загрузке MokManager прописывает нужный сертификат в UEFI, то не выйдет ли так, что какой-нибудь зловред сможет подпихнуть свой загрузчик (или гипервизор), подписанный сертификатом из этого загрузчика, в систему и загрузиться нормально, либо надо каждый раз будет выбирать сертификат при загрузке?

Текущие загрузчики, подписанные в дистрибутивах Linux, включают патчи для блокировки загрузки произвольных файлов. Либо они грузят все .efi-программы через стандартные функции UEFI, которые проверяют подпись, либо предварительно проверяют подпись через специальный протокол shim, и грузят самостоятельно.

MokManager при загрузке не прописывает сертификат самостоятельно (исключение — модифицированный shim в OpenSuse). MokManager из диска предлагает выбрать сертификат с файловой системы, и в диске он лежит в виде файла (файл ENROLL_THIS_KEY_IN_MOKMANAGER.cer в корне).

Зловред может использовать Super UEFIinSecureBoot Disk, настроив загрузку .efi без таймаута, но это сработает без необходимости физического вмешательства только в том случае, если вы уже запускали на компьютере Super UEFIinSecureBoot Disk и добавляли ключ через MokManager.

Тогда придется подписывать не только загрузчик, но и все файлы, которые предполагается загружать, либо импортировать ключи из всех файлов, которые предполагается загружать. И так на каждом компьютере.

Тогда придется подписывать не только загрузчик, но и все файлы, которые предполагается загружать

Что за глупость? Подписано или нет то, что загружает дальше загрузчик, это уже дело самого загрузчика. SecureBoot контролирует процесс доверенной загрузки только до стадии передачи управления от UEFI к загрузчику.

либо импортировать ключи из всех файлов, которые предполагается загружать.

Ничё не понял. Какие ключи у вас хранятся в файлах, которые предполагается загружать? И куда вы их собираетесь импортировать?

В нормальном случае файлы - это приложения UEFI, которые не обязательно являются загрузчиками чего-либо. Это может быть и UEFI shell, утилита тестирования памяти или утилита прошивки нового UEFI-firmware платы. В любом случае эти файлы не содержат никаких ключей, а содержат лишь электронные подписи, сделанные одним закрытых ключей, открытая часть которого прошита в UEFI.

И так на каждом компьютере.

Вы либо крестик снимите, либо трусы наденьте. Никто не говорил, что безопасность и доверие будут удобным. Но вы либо подписываете своим ключём загрузчик, которому вы лично доверяете, и далее доверяете всей загруженной системе. Либо вы пользуетесь этой поделкой из поста и делаете вид, что вы ей доверяете. Хотя к безопасности и доверию это не имеет никакого отношения. Это примерно так же, как ремень безопасности в машине пристегивать за спиной, чтобы машина не пикала о том, что ремень не пристёгнут.

GRUB2, который загружает EFI-файлы самостоятельно, не используя функции UEFI.

в grub для XHCI(usb 3) уже завезли драйвера, чтобы без UEFI?

Что за глупость? Подписано или нет то, что загружает дальше загрузчик, это уже дело самого загрузчика.

Это не так. Чтобы загрузить что-либо, загрузчик использует штатные функции UEFI, которые проверяют подпись загружаемого файла. Функция «linux» в grub - исключение, она загружает ядро в память и прыгает на entry point, но все остальные команды (chainloader, linuxefi) у стандартного grub не дадут вам загрузить произвольные файлы при включенном secure boot. Это справедливо и для других загрузчиков (refind, systemd-boot).

Если вы подпишите своим ключом uefi shell, и только его, вы также не сможете загружать произвольные неподписанные программы через него.

Ничё не понял. Какие ключи у вас хранятся в файлах, которые предполагается загружать? И куда вы их собираетесь импортировать?

Внутри .efi-файлов хранятся не только подписи, но и сооветствующие сертификаты, которыми был подписан файл. Чтобы, в случае флешки, запускались все программы, нужно импортировать сертификаты всех .efi-файлов, которые предполагается запускать. А если файл не подписан, то его придется подписывать своим ключом, или еще что-то придумывать. Морока.

UEFI2.0 Maybe Secure Boot

Я с трудом могу поверить, что с тремя с половиной пользователями GNU/Linux на десктопе вообще есть смысл бороться такими методами.

Хеловинские документы, гетзефактс и т.д.

Улучшения Windows в плане UX сделали в разы больше в борьбе с альтернативными системами, чем все эти «Get the Facts».

Нет, не сделали. Более того: в шиндовсе только ухудшения UI/UX были после семёрки.

Дизассемблирование тоже убивает весь смысл компиляции.

Смысл компиляции никак не связан со смыслом дизассемблирования.

Это по техническому факту. Но право есть хоть взламывать свой компьютер как угодно, хоть модифицировать.

Secure Boot не ограничивает пользователя: на любых материнских платах можно добавить любые сертификаты

SecureBoot может быть неотключаемым и не давать возможность загрузить свои ключи.

можно удалить сертификаты Microsoft, если хочется, можно сгенерировать свои ключи платформы и полностью им управлять.

Не на любой плате.

К сожалению, в среде пользователей Linux кем-то намеренно культивируется (по глупости или со злым умыслом) миф о том, что SB нужен только для того, чтобы Microsoft запретила ставить Linux на ноутбуки Surface.

С целью вреда сообществу и линуксу культивируется миф о том, что secureboot сделан для защиты от буткитов, а не от установки линукса.

SecureBoot может быть неотключаемым и не давать возможность загрузить свои ключи.

На x86 он обязан быть отключаемым, и добавить свои ключи можно, даже если в UEFI Setup нет интерфейса для этого.

Помимо glim, есть ещё https://github.com/aguslr/multibootusb

В этом проекте загрузок побольше, даже devuan есть, спасибо за наводку.

Зловред может использовать Super UEFIinSecureBoot Disk, настроив загрузку .efi без таймаута, но это сработает без необходимости физического вмешательства только в том случае, если вы уже запускали на компьютере Super UEFIinSecureBoot Disk и добавляли ключ через MokManager.

Именно это интересовало, получается, что если один раз загрузиться с помощью Super UEFIinSecureBoot Disk, то зловреду будет проще загрузить свою полезную нагрузку с нулевой задержкой в следующий раз.

А судя по этой новости https://arstechnica.com/information-technology/2018/10/first-uefi-malware-dis... , зловред может быть уже в uefi, так что загрузчик будет уже не нужен.

В любом случае проект полезный, особенно для тех, кто занимается восстановлением и ремонтом компьютеров.

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

Это зависит от того, как этот загрузчик написан. Можно и не использовать функции UEFI. Собственно, на этом и основана возможность работы этой приблуды из поста.

Функция «linux» в grub - исключение, она загружает ядро в память и прыгает на entry point

И это на самом деле плохо. Это именно тот самый ремень безопасности, застёгнутый за спиной.

но все остальные команды (chainloader, linuxefi) у стандартного grub не дадут вам загрузить произвольные файлы при включенном secure boot.

И это в общем-то правильно!

Чтобы, в случае флешки, запускались все программы, нужно импортировать сертификаты всех .efi-файлов, которые предполагается запускать. А если файл не подписан, то его придется подписывать своим ключом, или еще что-то придумывать. Морока.

Да! Просто на данном этапе это происходит из-за того, что отсутствует удобный инструментарий. Думаю, сообществу было бы полезнее сосредоточиться на его разработке, а не вот эту хрень делать - UEFIinSecureBoot Disk )

Это зависит от того, как этот загрузчик написан. Можно и не использовать функции UEFI. Собственно, на этом и основана возможность работы этой приблуды из поста.

Диск, в том числе, устанавливает UEFI secure policy, который разрешает загрузку любых файлов штатными средствами UEFI.

И это на самом деле плохо. Это именно тот самый ремень безопасности, застёгнутый за спиной.

Для этого существуют патчи для поддержки Secure Boot в GRUB2, который верифицирует подпись загружаемого ядра через команду linux, отключает загрузку модулей, и блокирует некоторые другие возможности. Дистрибутивы, поддерживающие Secure Boot, используют GRUB2 с этими патчами.

Да! Просто на данном этапе это происходит из-за того, что отсутствует удобный инструментарий. Думаю, сообществу было бы полезнее сосредоточиться на его разработке, а не вот эту хрень делать - UEFIinSecureBoot Disk

Удобный инструментарий для чего? Для запуска своих файлов уже есть shim и preloader, но они не идеально подходят для загрузочных флешек.

Зато отлично демонстрирует реальный технический уровень посетителей ЛОРа.

Скорее, распространённость гомоэротических фантазий.

Что прошивку вообще (а не только ME) не получится самому произвольно модифицировать. Ее подпись проверяется CPU. Boot Guard о ком ты сам же и говоришь.

Вы ошибаетесь, на подавляющем большинстве десктопных плат BG не включён.

Собственно, я лично модифицировал прошивку как минимум двух плат под CFL. Свежий микрокод, OROM-ки обновить, драйверы, вот это всё.

Ну и множество людей издевалось над прошивкой покруче: допустим, модификация CFL-плат под процы предыдущих поколений (SKL/KBL), никаких проблем не возникает.

Единственный минус, связанный с модификацией прошивки в том, что сейчас вендоры вместо посадки микрухи BIOS в кроватку (как во времена SKL/KBL) стали просто её припаивать и выводить на плате гребёнку для программатора, И у каждого вендора там своя распиновка, зачастую нигде не указанная. Но это уже мелочи.

Вы ошибаетесь, на подавляющем большинстве десктопных плат BG не включён.

Собственно, я лично модифицировал прошивку как минимум двух плат под CFL. Свежий микрокод, OROM-ки обновить, драйверы, вот это всё.

Кхм, не знал, думал все с прошивками.