Názory k článku
GRUB obsahuje chybu BootHole, která dovoluje obejít Secure Boot

Je to jen další z řady zranitelností Secure Bootu. Útočník může zranitelnou verzi GRUBu spustit třeba z USB (proč by bylo bootovaní z USB zakázáno, když máme secure boot, který nedovolí nastartovat nic nepovoleného) nebo vyndat disk a EFI partition editovat externě. Ovšem když bude vyndávat disk, může také připojit kleštičky k EEPROM a vypnout Secure boot.

"Útočník může zranitelnou verzi GRUBu spustit třeba z USB"
Domnívám se, že trochu demagogicky manipulujete :-). V okamžiku kdy má záškodník fyzický přístup k počítači selhává úplně všechno.

Tomu právě má bránit Secure Boot. Já mám třeba na notebooku šifrovaný celý disk, samozřejmě kromě zavaděče. Ten je chráněn podpisem a není možné jej nahradit vlastním kódem, který by mi ukradl heslo a někomu ho poslal. Fyzický přístup útočníkovi nepomůže. Pokud ovšem nezneužije takovou kritickou díru.

Odhodlanému útočníkovi s fyzickým přístupem se brání těžko. Může někam přidat hardwarový keylogger s odesíláním přes LTE, může vyměnit notebook za nový stejně vypadající, který se jen zaptá na heslo a odešle ho útočníkovi.... Možností je spousta. Ano, uznávám, je to dražší a pracnější a "náhodného pobudu" to možná odradí.

Já mám pocit, že secure boot je mnohem více použitelný pro bránění akcí typu jail break, než k reálnému zabezpečení - od toho je lepší právě TPM, kdy víte kontrolní součty zavaděče, jádra, biosu, konfigurace. Pokud se někde v procesu něco změní, tak to víte. Oprava takového chyby také není výrazně složitá - daná součást se aktualizuje a následně se aktualizují i součty.
I fyzický útok je na to obtížnější, než na secure boot (ale teoreticky možný, dokud je TPM samostatná součástka).

Secure Boot může útočník vypnout v setupu, případně i zavést vlastní klíče. Bránit tomu má přístupové heslo, ale *všechny* firmwary ("BIOSy") mají pevná výchozí hesla. Když se útočník dostane fyzicky k Vašemu notebooku, je vypnutí SB otázkou jednotek minut. Bez speciálních nástrojů, rozebírání stroje a podobných vylomenin.

Nejen USB. Napadá mě třeba PXE. To je zároveň i jeden ze scénářů útoku, kde nemusíme předpokládat fyzickou přítomnost.

Dále se nabízejí různé rootkity, které chtějí začít působit co nejdříve.

U nového notebooku přijdu nastavení BIOSu a případné PXE je jedna z věcí, které vypínám. Ale nedělám si iluze, že tak činí každý...

PXE je typicky případ jak se většinou vlamu do korporatniho notasu - už třetí firma. Ono je to zapnuté z důvodu rychlého reimage nebo privisioningu.

Tuto zranitelnost nepůjde odstranit aktualizací apt update;apt upgrade ?

Neříká se, že jakmile získá škůdce fyzický přístup k počítači, tak je možné předpokládat jeho ovládnutí?

To má relativně snadné řešení - k ověření integrity grubu použít TPM a jeho measurements. Pokud opravdu jde o zaručení integrity platformy.

Ne všechny stroje, které umí secure boot mají i nainstalované TPM.

Ako je na tom ked mam encryptovany /boot ?
Je to viac secure alternativa ?

| EFI | LUKS1 /boot | LUKS2 LVM (root&swap) |

Admin password do BIOSu na Dell strojoch zamedzia boot s USB. Mozno idelany by bol aj BIOS Disk password, ale ten pre NVME disky zatial nieje mozny..

1. 8. 2020, 22:22 editováno autorem komentáře

s /boot na LUKS utocnik muze nahradit Grub EFI binarku (kterou zajistujes odemceni LUKS) za vlastni s keylogerem a odchytit tve LUKS heslo...

vhodnejsi je pouzit misto Grub zavadec sicherboot, s tim ze v EFI smazes vychozi (=Microsofti) klice, pres sicherboot vygenerujes vlastni, pres jeho KeyTool naimportujes tyto sve klice do EFI, sicherboot pak pri kazde instalaci/aktu­alizaci jadra a/nebo initramdisku vygeneruje "svou" EFI binarku obsahujici jadro+initramdisk a podepise je tvejma klicema... (+ to zminene heslo do biosu)

tedy utocnik sice ma pristup k tvemu "zabalenemu" (do EFI formatu) initramdisku kterej zajistuje odemceni LUKS na /boot, nicmene tim ze mas s SecureBoot+Vlas­tniKlice zamezen start cehokoliv jineho nez tebou podepsaneho, utocnik to nema jak kompromitovat...

EDIT: k "nema jak kompromitovat" mysleno normalni cestou, stale ale muze udelat to ze zrusi tve heslo do biosu, vypne secure boot (nebo obnovi MS klice ci da sve vlastni), prida zavadec s keylogerem... k tomu by potreboval stroj rozebrat a odpajet zalozni baterku a/nebo preprogramuje eeprom...

2. 8. 2020, 23:30 editováno autorem komentáře

A nestacilo by len po starte skontrolovat checksum grubx86.efi a v pripadne ked sa nieco zmeni, tak viem ze som kompromitovany a potom nasledne konat.. menit vsetky LUKS hesla/kluce a znovu nainstalovat GRUB atd. ?

Myslim si ze fyzicky utok na notebook je utok z najmensim percentom. Ked mi ho ukradnu, tak sa k datam nedostanu iba ze by ukradli aj mna a nejaky "Boris" by to uz somna vytlkol ale to by uz bolo asi jedno vtedy :-)

Záleží, jak sofistikovaný útok bude, ale útočník může v podstatě vše virtualizovat a předhodit ke kontrole původní binárku.

Fyzický útok – záleží. Krádež nebo očividná manipulace vypnutého notebooku zašifrovaného silným a unikátním heslem nemusí být pro znalého a dbalého uživatele z hlediska krádeže dat problém. Pokud něco z předpokladů neplatí (zapnutý notebook, nenápadná modifikace, slabé heslo, neznalý nebo nedbalý uživatel, slabé nebo opakovaně použité heslo), už to s tou bezpečností nemusí být až tak slavné...

@ptrj

nez bys udelal kontrolu muze davno pres par_radkovej_u­tocnikuv_skrip­t.sh vratit regulerni grubx86.efi, odeslat odposlechnutej luks klic, zajimave soubory z /etc, tveho home, atd...

obecne je proste vhodne v ramci moznosti co nejvice (kdyz uz nelze vsem) moznostem predejit, nez kontrolovat "nejak" az nasledne zda te nekdo napadl a menit hesla, resp. pokud mas aktivni SecureBoot+vyh­radne_vlastni_kli­ce muzes tu kontrolu pridat jako detekci pruniku pri bugu kterej by SecureBoot obesel, ale urcite to nemit jako "nahradu" "bezpecnosti" pri vypnutem SecureBoot, jak sem tvoji otazku pochopil :)

EDIT: + treba doporucuju odebrat prava adresari /boot pro skupinu a ostatni
sudo chmod go-rwx /boot
tedy by vzdaleny utocnik kterej by pres nejakej deravej program bezici pod uzivatelem nemel pristup na EFI oddil kterej je pod /boot i presto ze EFI oddil je bezpravovej FAT...

4. 8. 2020, 01:12 editováno autorem komentáře