Уязвимость в Linux позволяет внедрять вредоносный код через Initramfs

Бездумно шифруешь все ты, а религиозный почему-то я. Ничего не попутал, 🤡?

Это особенность дебианспецифичного initramfs-tools. Есть подозрение, что и в dracut’е такого нет.

Решение уже давно есть: https://0pointer.net/blog/brave-new-trusted-boot-world.html - просто дистры по обыкновению тормозят с внедрением.

Так ведь «сделанное любым челом» не совместимо с безопастным режимом по умолчанию.

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

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

Ну опять же - датчик вскрытия.

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

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

Но вообще самый простой случай — это тупо шифровать initramfs симметричным шифром по паролю, введённому пользователем. Ядро при запуске спрашивает пароль с VGA-консоли, распаковывает initramfs и запускает.

Таким образом, злоумышленник, имеющий доступ к локальной консоли, просто не сможет добраться командной оболочки, если не знает пароля.

Оно же завязано на скомпрометированный ТПМ

Но она не соблюдена, т.к. в цепочку нужно внедрить сторонний код сторонних модулей и при этом дать юзеру полный доступ к хранилищу ключей, т.е. реальная взломостойкость системы в целом не выше чем у браузера.

Но вообще самый простой случай — это тупо шифровать initramfs симметричным шифром по паролю, введённому пользователем. Ядро при запуске спрашивает пароль с VGA-консоли, распаковывает initramfs и запускает.

Отличное решение! И двухступенчатая система шифрования дисков. Юзер ложит свои ключи в зашифрованный им же инитрд и системе есть чем расшифровать все диски при запуске. А для энтерпрайзных безопастников можно вместо пароля использовать аппаратный ключ-брелок или аналог.

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

Шифровать убунту все равно что жарить гвозди.

При следующей загрузке, когда владелец введёт правильный пароль, вредоносный код выполнится

Кроме того, метод, описанный ERNW, требует заранее подготовленной USB-флешки со скриптами и инструментами для модификации initramfs, внедрения вредоносного кода и его перепаковки, чтобы процесс загрузки прошёл без ошибок.

Я бедная африканская уязвимость, не могли бы вы в UEFI указать загрузку с флешки и отойти? Все можете подходить, перезагружать систему, нет не смотрите на usb порты. Может, просто пароль скажите, а? А то с первого раза может и не получиться.

Все-таки уязвимости и вирусы на винде гораздо более user friendly. Тут конечно, линуксу ещё догонять и догонять..

Решето, омг, надо что-то срочно делать! Линусу звонили?

Я просто ставлю ATA password на весь SSD. Да, hardware encryption имеет дурную репутацию, но зато конфигурация проста как пень.

Самый простой способ - /boot на шифрованном разделе + grub, запрашивающий пароль.

на скомпрометированный ТПМ

Кем скомпрометированный? Не тобой же - твой интеллектуальный уровень по комментам видно.

Про этот ваш Руст уже набрасывали?

А почему критическую в кавычках? Уязвимость реально критическая, тот факт что большинство дистрибутивов до сих пор не способны организовать цепочку безопасной верифицируемой загрузки (в отличии от винды кстати) это позор. И если прятать голову в песок и пытаться замести проблему под ковёр, то она так никогда и не решится.

яйца для варки кладут в холодную воду

К терморектальному криптоанализу добавляются новые методы.

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

Совершенно не обязательно: флешка была воткнута во время правки initrd. А к тому времени, как комп оказался у вас, уже все закончилось: initrd уже пропатчен, и в нем уже сидит троян.

Собственно как уже не раз в этом треде было сказано: это давно известная беда, с давно готовым решением — UKI.

Что не понятно, так это зачем современные популярные дистрибутивы до сих пор на EFI системы ставят grub, а воркфлоу с UKI приходится костылить руками.

Неподписанный UKI тоже можно пропатчить же.

Конечно можно. Но зачем его оставлять неподписанным?

Было: два файла, в одном ядро, в другом ФС с кучей скриптятины, конфигов и модулей ядра.

Стало: один файл, в котором ФС с кучей скриптятины, конфигов и модулей ядра, а ещё само ядро.

Усложнили!

В старых биосах был такой пунктик в «System Status», но тогда биос редко кто паролил, да и решалось это просто джампером «Clear CMOS». BIOS показывает, что " Case opened: Yes", но толку от этого. А вот сейчас уже да, это довели до ума, но не все и не везде.

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

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

Ядро может грузиться и без initrd как такового. Модули встраиваются в ядро, алгоритм шифрования – тоже модуль, и его тоже можно встроить в ядро. А пароль ядро может и запросить. Всë это можно, но я пока на UKI переходить не готов. Да и на машине нет такой информации, которая была бы критична.

Ну да, это самый надëжный способ защиты.

пароль ядро может и запросить

Как это настроить?

Тут скорее вопрос в том, почему у инитрд подписи нет.

Потому, что ядро компилируется на сервере убунты и ключ лежит там же. А initrd собирается на компьютере пользователя и ключа убунты там нет. В целом я не вижу проблем генерировать второй ключ и прописываеть его в доверенные, хз, почему так не делают. А вообще я не понимаю нужды генерировать initrd на стороне пользователя.

Открываешь корпус

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

Обзор от ИИ

It is possible to boot a Linux system with a LUKS encrypted root partition without using an initrd (initial ramdisk) or initramfs, but it requires careful configuration and some limitations. The primary challenge is providing the necessary tools and information to the kernel to decrypt the root partition before mounting it. Here’s a breakdown of the process and considerations:

1. Kernel Configuration:

The kernel must be compiled with built-in support for the necessary storage drivers (e.g., SATA controller drivers, filesystem drivers like ext4) and the dm-crypt module for LUKS encryption. Modules cannot be used: for these functionalities; they need to be compiled directly into the kernel.

2. Bootloader Configuration:

The bootloader (e.g., GRUB) needs to be configured to pass the correct parameters to the kernel, including: root=/dev/mapper/<mapper_name>: Specifies the decrypted root partition. The <mapper_name> will be the name assigned to the LUKS volume when decrypted (e.g., luks-UUID or a name defined in /etc/crypttab).

cryptdevice=UUID=<uuid>:<mapper_name>: Specifies the LUKS encrypted device and the desired mapper name. The UUID refers to the LUKS superblock. cryptkey=root:UUID=<uuid>: (Optional) If using a keyfile, specify its location. The UUID here refers to the keyfile’s location, often on the /boot partition.

Keyfile/Passphrase:

If using a passphrase, it needs to be entered at the bootloader prompt or through other means if the bootloader supports it (e.g., GRUB’s cryptodisk functionality).

If using a keyfile, it needs to be accessible to the bootloader. Consider using a keyfile on a separate, encrypted partition, and potentially a removable device for added security.

3. Limitations and Considerations:

Complexity: Setting up a system this way is significantly more complex than using an initrd or initramfs.

Security: If the bootloader or kernel is compromised, the LUKS encryption is vulnerable. Hardware Dependence: The kernel needs to include drivers for your specific hardware, making it less portable. Boot Time: While removing initrd/initramfs can potentially speed up boot times, the initial setup complexity and potential for errors might negate those gains.

4. Alternatives:

Encrypted initrd/initramfs: The easiest and most recommended approach is to keep the initrd/initramfs but encrypt it as well, using a bootloader that supports it (e.g., GRUB).

Keyfile on /boot: If you’re using a keyfile, storing it on the /boot partition is a common and relatively secure practice, especially if /boot is on a separate partition from the root filesystem.

In summary, while technically feasible, booting without initrd or initramfs with LUKS requires significant expertise and carries security risks. It’s generally recommended to utilize the standard initrd/initramfs approach with LUKS encryption for a more robust and secure system.

Я этого не делал, не знаю :)

Ну т.е. способа вводить пароль через ядро он не знает. Думаю, его и нет. Реализовать может и можно, но не реализовали. Максимум - использование encrypted /boot в grub.

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

В принципе полезная новость, так как вот эти ребята:

Риск оправдан только при атаке на важные цели — бизнес, IT-инфраструктуру, активистов или политиков.

будут более активно защищаться от Evil Maid атак.

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

Было - 2 команды + 2 строки в конфиге. Стало - траходром + ключи подписи.

Кстати, 2 файла с кучей скриптятины никуда не делись, просто над ними дополнительный уровень надстроили.

Я тоже ограничиваютсь шифрованием хомяка, и то всего на 1 ноуте из всего.

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

Стало - траходром + ключи подписи.

Не-не-не, ключи-подпичи это если тебе нужен Secureboot. Оно и в случае ядра+инитрд будет траходром и ключи-подписи.

Кстати, 2 файла с кучей скриптятины никуда не делись, просто над ними дополнительный уровень надстроили.

Да, но в конечном итоге и загрузчик проще настраивать и ключи-подписи проще делать, и всем хорошо.

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

Да.

активистов или политиков

LGBT активистов, я надеюсь? Больше же уже нечего защищать. Только бизнес и их. И их политиков.

Опять уязвимость, которую надо канпелировать, устанавливать и т.д... Задолбали. Найдите уже такое чтобы я открыл сайт, и вирус прямо через меня Белый Дом парализовал бы. Я бы хоть порадовался.

В этих ТПМ по 2 аппаратных уязвимости в год находят в среднем.

Какие конкретно? Где?

TPM2 анонсирован больше 10 лет назад - то есть должно быть 20 аппаратных уязвимостей. Где хотя бы одна?

Почему ты всегда врёшь как сивый мерин?

В чем драма-то?

Ты мышкой в ссылку из новости попасть не можешь или что конкретно у тебя не получается?

Еще одна уязвимось уровня «зраститя, я оллбанскей вирос. В силу неразвитости IT-инфраструктуры у нас дома пойжалуста, вбейте ваш пороль в это поле и нажмите кропку САБМИТ»?

Никогда не понимал, да и никто так внятно и не может ответить на примитивный вопрос: «Зачем вообще давать физический доступ кому-то постороннему к устройству с чувствительной информацией? Как это, не мочь защитить критическое устройство физически, ну не знаю, сейфом или чистой комнатой?»

Вангую, что в будущем появятся новости в духе «уязвимость в Linux позволяет внедрять вредоносный код через файл с образом ядра»

Я тоже ограничиваютсь шифрованием хомяка, и то всего на 1 ноуте из всего.

Как настроил?

https://www.opennet.ru/opennews/art.shtml?num=47091 https://www.opennet.ru/opennews/art.shtml?num=47866 https://www.opennet.ru/opennews/art.shtml?num=47597 https://www.opennet.ru/opennews/art.shtml?num=53149 https://www.opennet.ru/opennews/art.shtml?num=52487 https://www.opennet.ru/opennews/art.shtml?num=51862 https://www.opennet.ru/opennews/art.shtml?num=56149 https://www.opennet.ru/opennews/art.shtml?num=59093 https://www.opennet.ru/opennews/art.shtml?num=58758 https://www.opennet.ru/opennews/art.shtml?num=61432 https://www.opennet.ru/opennews/art.shtml?num=59702 https://www.opennet.ru/opennews/art.shtml?num=62475 https://www.opennet.ru/opennews/art.shtml?num=61817 https://www.opennet.ru/opennews/art.shtml?num=62574

Это только на опеннете, беглый осмотр вопроса. Ты разумеется заявишь что это по большей части не аппаратные а програмные проблемы, но ты не сможешь объяснить WTF любая уязвимость в прошивке, систме удалённого инжинерного доступа, загрузчике, гипервизоре, системд и ещё хер знает чём приводит к утеканию секретных ключей из доверенного хранилища.

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

luks + /etc/cryptab, стандартный рецепт дебиана.

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

А во вторых уборщица может подойти, взять диск вечером а вернуть его заражённым буткитом утром (или вообще сделать всё за 10 минут на месте). Далее директор придёт и запустит вирус ни о чём не подозревая.

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

Вообще, есть только один критерий безопасности - если владелец компа (любого, от PC до однокристалки в тостере) не имеет полного и абслютного контроля над своей собственностью, ни о какой безопасности речь в принципе не может идти никак и никогда.

Ну правда - это же полный идиотизм рассуждать, например, о сетевой безопасности, если, например, совершенно неизвестно что за код крутится в baseband SoC WiFi модуля. Я уж молчу про всякие IntelME и AMD PSP.