BootHole-bug in Grub2 maakt alle apparaten met Secure Boot kwetsbaar

Verschillende fabrikanten komen met een fix voor een kwetsbaarheid in Grub2 die vrijwel alle apparaten met Secure Boot treft. Die kwetsbaarheid maakt het mogelijk om code uit te voeren tijdens het startproces, ook als Secure Boot aanstaat.

Het lek wordt BootHole genoemd en werd ontdekt door beveiligingsbedrijf Eclypsium. Het lek zit specifiek in Grub2, de Grand Unified Bootloader die door de meeste Linux-systemen wordt gebruikt. Ook Windows-systemen zijn kwetsbaar als die Secure Boot gebruiken waarbij Microsoft zelf optreedt als certificaatautoriteit, wat bij praktisch alle Windows-systemen het geval is. De kwetsbaarheid was volgens de onderzoekers op alle apparaten met Secure Boot uit te voeren, zelfs als Grub2 niet was ingeschakeld. De bug heeft code CVE-2020-10713 gekregen.

De kwetsbaarheid is vrij ernstig, met een CVSS-score van 8.2. Wel is ze in de praktijk lastig uit te buiten. Een aanvaller moet het grub.cfg-configuratiebestand aanpassen en heeft daarvoor in ieder geval roottoegang tot een systeem nodig. Door de grootte van een token in grub.cfg aan te passen kan een aanvaller een buffer overflow veroorzaken. Als er vervolgens malware wordt ingeladen, stopt de parser niet automatisch met uitvoeren zoals de bedoeling is, maar wordt die malware juist ingeladen tijdens het bootproces.

Nadat de onderzoekers hun bevindingen hadden doorgegeven aan verschillende fabrikanten, vonden die zelf nog andere kwetsbaarheden in Grub2. Ubuntu-ontwikkelaar Canonical heeft het over zeven kwetsbaarheden. Het gaat om andere buffer overflows en een use-after-free-kwetsbaarheid.

Tientallen fabrikanten van Linux-systemen hebben inmiddels patches uitgebracht. De meeste hebben daarvoor nieuwe Grub2-packages uitgebracht. Sommige ontwikkelaars zoals RedHat zeggen wel dat de praktische impact van de kwetsbaarheid meevalt.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (54)

Simpel uitgelegd: het grootste probleem is dat vrijwel alle GRUB2 gebaseerde boot-loaders uit 2 delen bestaan.
De eerste is de zogenaamde SHIM (die een Microsoft gesigned certicifaat heeft) en de 2e is de eigenlijke bootloader die door die shim geladen wordt.
Die 2e heeft GEEN certicaat en is makkelijk te vervangen (door een kwaadwillende) omdat het pad naar de file in aan platte tekst configfile staat en de SHIM controleerd niet of die tekst-file te vertrouwen is.
Uiteraard heb je wel root-access nodig om die tekst-file aan te passen.
Door dat laatste is het risco wel vrij klein. Als iemand al zo binnen is op je systeem ben je al de pineut. Dit maakt het alleen een graadje erger.

Overigens is ieder SecureBoot systeem, ook Windows zonder aanwezigheid van GRUB, op deze manier te manipuleren als iemand root/administrator access (eventueel door te booten van external media) kan krijgen tot de harddisk waar de EFI folder/partitie op staat.
De attacker kan in dat geval de originel bootloader vervangen door een GRUB2 shim, die een gemanipuleerde deel 2 van GRUB laten starten, die dan weer de originele loader doorstart. Gebruiker merkt niks, maar de malwere zit verborgen in RAM en heeft volledige toegang tot alles.

Je uitleg klopt helemaal, op 1 ding na, en dat is dat Bitlocker zal weigeren te booten zonder herstelsleutel als je via een andere bootloader doorstart. Een versleutelde Windows-installatie waarvan de sleutel in de TPM zit (en waar je dus niet eens per se een wachtwoord voor in hoeft te geven) zal als het goed is dus niet kwetsbaar zijn voor de aanval zoals hier beschreven.

Als je een ander OS gebruikt is het overigens mogelijk de Microsoft-certificaten niet te vertrouwen en je eigen te gebruiken. Je moet dan een eigen sleutel genereren en die in de UEFI stoppen. Als je je UEFI goed dichttimmert met een sterk wachtwoord en je je bootloader goed instelt (full-disk encryption!), kan je computer als het goed is dan geen andere bootloader meer opstarten. Dit kan in een bedrijf met zeer vergrendelde Linux-computers (zoals de NSA) een zeer sterk beveiligingsmechanisme vormen.

En in de praktijk zal dat weinig effect hebben. De gebruikers van een systeem waarbij de Bitlocker versleuteling optreed, zeker in corporate systemen, bellen met hun servicedesk of volgen de online acties om de herstelsleutel te achterhalen en bootten vervolgens vrolijk door. Met de infectie. Bitlocker versleutelingen kijkt de gemiddelde servicedesk niet meer van op omdat meerdere malen een fout wachtwoord invoeren op een systeem, of een issue met de TPM na een Windows of BIOS update, ook een vergrendeling oplevert.

Je was me voor, maar ik wilde precies hetzelfde zeggen.
Komt dagelijks voor.
Heb vanmorgen nog 2 klanten gehad met een BitLocker probleem.
De een (nieuwe medewerker) had geen idee meer van zijn PIN (gisteren initieel gezet) en voerde nu hardnekkig de verkeerde in.
De andere was zelf met de Bios aan het klooien geweest om virtualisatie aan te zetten en hij had gelijk ook maar de TPM gereset. "Volgens de instructie op het Internet was dat ook nodig..."

[Reactie gewijzigd door TonnyTonny op 30 juli 2020 14:19]

Dat Secure Boot inherent onveilig is door de de facto beveiliging toe te vertrouwen aan een enkele partij is natuurlijk niets nieuws.

In this article we proved the existence of not enough reliable bootloaders signed by Microsoft key, which allows booting untrusted code in Secure Boot mode.

(...)

I assume that Kaspersky bootloader signature certificate will not live long, and it will be added to global UEFI certificate revocation list, which will be installed on computers running Windows 10 via Windows Update, breaking Kaspersky Rescue Disk 18 and Silent UEFIinSecureBoot Disk. Let's see how soon this would happen.

Het is voor mij onduidelijk of de kwetsbare bootbestanden ondertussen inderdaad geblokkeerd zijn via de CRL.

Verder heeft Microsoft een geschiedenis van het ondertekenen van kwetsbare executables. Denk bijvoorbeeld aan MechAssault, 007: Agent Under Fire en Splinter Cell voor de originele Xbox. Ik verwacht dus ook niet snel dat dit in de toekomst zal worden voorkomen.

Dat is dan ook het probleem: er wordt nu eigenlijk weinig beveiliging toegevoegd, maar wel ingewikkelde procedures om je product bootable te maken op systemen zonder modificatie.

[Reactie gewijzigd door The Zep Man op 30 juli 2020 10:18]

De links in het artikel naar de info van de verschillende distributies. Er is dus al een fix beschikbaar.

Microsoft
Security advisory
https://portal.msrc.micro...idance/advisory/ADV200011
UEFI Forum
Updated Revocation List
https://uefi.org/revocationlistfile
Debian
Security advisory
https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot
Canonical:
Security advisory
https://ubuntu.com/security/notices/USN-4432-1
KnowledgeBase article
https://wiki.ubuntu.com/S...ase/GRUB2SecureBootBypass
Red Hat
Customer documentation
https://access.redhat.com...abilities/grub2bootloader
CVE information
https://access.redhat.com/security/cve/cve-2020-10713
Vulnerability response article
https://access.redhat.com...abilities/grub2bootloader
SUSE
Security advisory:
https://www.suse.com/c/su...-grub2-secure-boot-issue/
Knowledge Base article:
https://www.suse.com/support/kb/doc/?id=000019673
HP
Security advisory
HPSBHF03678 rev. 1 – GRUB2 Bootloader Arbitrary Code Execution
HPE
Security advisory
https://techhub.hpe.com/e.../Boot_Hole/boot_hole.html
VMware
Knowledge Base article
https://kb.vmware.com/s/article/80181
Upstream Grub2 project
GRUB2 Git Repository
GRUB Developer Mailing List

Is dit niet eerder een bug in secure boot? Daar Linux en Windows er "last" van hebben en misschien andere bootloaders ook?

urrr... nee....

Secure boot zorgt er voor dat er alleen een gesignde bootloader kan laden. Grub is die gesignde bootloader. Het probleem ontstaat pas nadat secure boot zijn werk gedaan heeft, namelijk in de bootloader.

Het OS is dan ook irrelevant; zodra je Grub gebruikt om dat OS te laden ben je kwetsbaar. De volgorde SecureBoot - Grub - OS heeft een kwetsbaarheid in het tweede deel; je bent "secure" door Grub te laden, Grub is kwetsbaar, onafhankelijk van het OS wat door Grub geladen wordt.

De kwetsbaarheid was volgens de onderzoekers op alle apparaten met Secure Boot uit te voeren, zelfs als Grub2 niet was ingeschakeld.

En uit de bron zelf

The problem also extends to any Windows device that uses Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority. Thus the majority of laptops, desktops, servers and workstations are affected,

De bron heeft het ook over andere type devices, die vatbaar zijn.

Dus het is zover ik kan lezen niet specifiek een grub probleem en daar er meerdere bootloaders het zelfde probleem hebben, vind ik het een bug in de secure boot.

Als ik onder linux secure boot heb aanstaan, heb ik al "problemen" met het laden van modules.

De bug kan ook misbruikt worden op systemen die GRUB niet gebruiken door op admin-niveau toch stiekem GRUB te laden en de code uit te voeren.

De gebruiker zal het niet merken en het systeem is dan toch kwetsbaar.

Ook Windows-systemen zijn kwetsbaar als die Secure Boot gebruiken waarbij Microsoft zelf optreedt als certificaatautoriteit, wat bij praktisch alle Windows-systemen het geval is. De kwetsbaarheid was volgens de onderzoekers op alle apparaten met Secure Boot uit te voeren, zelfs als Grub2 niet was ingeschakeld.

Wel een beetje een misleidende titel als ook zowat elk Windows-systeem op de planeet er kwetsbaar voor is
Eerder een kwtesbaarheid in "Secure Boot" lijkt me dus?

Het artikel van Eclypsium is ook niet heel duidelijk.
Wel zeggen ze het volgende:

The problem also extends to any Windows device that uses Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority.

Als je dan kijkt naar de advisory door MS: https://portal.msrc.micro...idance/advisory/ADV200011 en in bijzonder dit stuk:

To exploit this vulnerability, an attacker would need to have administrative privileges or physical access on a system where Secure Boot is configured to trust the Microsoft Unified Extensible Firmware Interface (UEFI) Certificate Authority (CA). The attacker could install an affected GRUB and run arbitrary boot code on the target device. After successfully exploiting this vulnerability, the attacker could disable further code integrity checks thereby allowing arbitrary executables and drivers to be loaded onto the target device.

Ik denk dus dat het idee is dat door de bug in GRUB (die vertrouwt wordt door "Microsoft Unified Extensible Firmware Interface (UEFI) Certificate Authority (CA)." je GRUB kan installeren op een Windows systeem (waar voorheen geen GRUB op stond) en zo het boot proces kan aanpassen.
Je zou dit met elke stuk code kunnen proberen, maar die wordt niet vertrouwt door secure boot.
Zie ook de andere stukken in de advisory:

As part of enabling this feature, Microsoft signs boot code both for Windows and 3rd-parties including Linux distributions
...
The GRUB vulnerability provides a way to bypass the UEFI Secure Boot security feature for any system that trusts the Microsoft 3rd-party UEFI signer, which includes many PCs.

[Reactie gewijzigd door LEDfan op 30 juli 2020 10:37]

Maar... Dat is het hele punt van GRUB tegenwoordig? GRUB handelt het hele "secure boot"-gebeuren af en daarna boot je gewoon in wat je wilt, toch? Of zijn kernels ook signed? (Ik dacht van niet?)

Ja, maar ik denk dat het probleem is dat een aanvaller grub kan installeren op een windows pc waar geen grub opstond en dan vervolgens het boot process kan aanpassen door de bug in grub.

Zo ver ik weet, als je "secure" wil booten, moeten je kernel en alle modules ook gesigned zijn.

ja ik snap die opmerking ook niet. Is nu elk Windows systeem kwetsbaar, of alleen als ook Grub aanwezig is? Mij onduidelijk.

Elk systeem is kwetsbaar, of ze nu GRUB gebruiken of niet. Het was voor mij ook niet meteen duidelijk en heb even doorgeklikt naar https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/

The vulnerability affects systems using Secure Boot, even if they are not using GRUB2.

De onderzoekers ontdekten het probleem in GRUB maar de ontdekking werkt ook zonder dat GRUB op het systeem staat. De titel maakt het wat verwarrend, het lijkt alsof enkel systemen met GRUB kwetsbaar zijn, al blijkt dat alle systemen kwetsbaar zijn.

All signed versions of GRUB2 that read commands from an external grub.cfg file are vulnerable, affecting every Linux distribution. To date, more than 80 shims are known to be affected. In addition to Linux systems, any system that uses Secure Boot with the standard Microsoft UEFI CA is vulnerable to this issue. As a result, we believe that the majority of modern systems in use today, including servers and workstations, laptops and desktops, and a large number of Linux-based OT and IoT systems, are potentially affected by these vulnerabilities.

[Reactie gewijzigd door Aegir81 op 30 juli 2020 10:21]

kijk, dat maakt het duidelijker... vraag me dan nog af hoe een Windows systeem exploited kan worden.

Ik ben geen beveiligingsexpert maar als ik het goed begrepen heb kunnen ze door een buffer overflow kritische informatie overschrijven en zo al controle over de pc krijgen voor het OS geladen wordt, hackers krijgen dus permanent toegang tot het OS (ook al wordt bijv. een gebruiker verwijderd of worden de rechten van die gebruiker aangepast).

De code voor de buffer overflow kan echter enkel uitgevoerd worden door iemand met admin-rechten, er moet dus al op een andere manier toegang gekregen worden tot het systeem: dat kan rechtstreeks zijn (iemand liet zijn pc open staan), maar dat kan ook via social engineering bijv. door iemand code te laten uitvoeren op een computer, of misschien door een bijlage in een mail te stoppen (opnieuw, ik ben geen expert ;-)).

Edit: -1, wat is er ongewenst aan deze post?

[Reactie gewijzigd door Aegir81 op 30 juli 2020 10:58]

Maar de buffer overflow zit in GRUB, dus heb je wel GRUB nodig om die te kunnen exploiten.
Zoals ik het begrijp (ik kan ook fout zijn) kan een attacker GRUB installeren op een Windows PC (met secure boot) omdat GRUB vertrouwt wordt, om dan vervolgens de bug in GRUB te exploiten.

Klopt, dat is volgens mij ook hoe het werkt.

GRUB kan geladen worden op een Windows-computer waar het nog niet op staat en zo stiekem de exploit installeren.

[Reactie gewijzigd door Aegir81 op 30 juli 2020 10:45]

Goede uitleg. Snap ook niet waarom jouw reply (en mijn vraag) gedownmod wordt. Lijkt me helemaal ontopic te zijn.

Dat laatste dus. De kwetsbaarheid zit in GRUB2.

Nee, ze is ontdekt in GRUB 2 maar ze werkt ook op computers waar GRUB niet gebruikt wordt.

De bug zit in GRUB 2, en het deel waar Microsoft bij komt te kijken is dat zij de GRUB2 (shim) signed hebben (allé, als CA) die dus nu exploitbaar blijkt te zijn.

Men heeft dus nu een 'loper' die men overal op Secure Boot systemen kan gebruiken, waardoor dus ook op systemen waar Windows draait.

Men heeft dus nu een 'loper' die men overal op Secure Boot systemen kan gebruiken

Alleen bij systemen waar toevallig die specifieke key van Microsoft op staat. (Partijen die daadwerkelijk om security geven zullen niet een beleid "ik vertrouw alles wat Microsoft vertrouwt" volgen.)

[Reactie gewijzigd door Z_God op 31 juli 2020 13:31]

Een Windows systeem is kwetsbaar, aangezien een kwetsbare GRUB2 geïnstalleerd kán worden. Deze kwetsbare GRUB2 versies hebben immers een Microsoft signature, en zullen door systemen met Windows erop als "secure" gezien worden.

Er zitten twee kanten aan Secure Boot,
1. Het zorgt ervoor dat de code die je inlaadt, bootloader, kernel, gesigned meoten zijn.
2. Het verteld de ingelade code dat er geen onbetrouwbare code is ingeladen.

Als we Windows in dit verhaal betrekken, doorbreekt deze bug het tweede punt.
Wat er zou kunnen gebeuren:
1. UEFI laadt GRUB2
2. GRUB2 laadt unsigned code
3. GRUB2 laadt Windows

Op dit moment ziet Windows dat het in "Secure Boot" mode is geladen, en gaat er van uit dat stap 2 onmogelijk gebeurd is. Als de code die in stap 2 is ingeladen malware is, dan is deze mogelijk niet door Windows te detecteren.

een windows systeem is kwetsbaar als je de windows bootloader gaat vervangen door een grub bootloader waarvoor je al toegang tot het filesysteem moet hebben ( wat je normaal niet hebt wegens bitlocker )

Wat is eigenlijk het nut van Secure Boot voor een consumenten desktop pc die thuis staat? Of een consumenten laptop die niet voor werk wordt gebruikt?

Ik schakel het altijd uit.. daarna veeg ik de schijf (Windows) leeg tijdens de Ubuntu Budgie installatie.

Wat is eigenlijk het nut van Secure Boot voor een consumenten desktop pc die thuis staat? Of een consumenten laptop die niet voor werk wordt gebruikt?

Het idee erachter is dat het voor malware moeilijker wordt om kritieke bootbestanden te wijzigen om zichzelf zo dieper in het systeem te kunnen nestelen. Daar zitten een paar haken en ogen aan:
• Als malware lokaal kan draaien heb je al verloren. Malware kan CRL updates blokkeren.
• De toegevoegde beveiliging is beperkt, zoals genoemd in het artikel en in mijn andere reactie. Malware kan kwetsbare signed UEFI bestanden gebruiken om eigen code te draaien.
• Waarschijnlijk zijn de kosten die gemaakt worden om secure boot te ondersteunen hoger dan de besparing die de beveiliging oplevert. Tegelijkertijd geeft het een enkele partij (Microsoft) veel macht.

[Reactie gewijzigd door The Zep Man op 30 juli 2020 10:28]

Secure boot gaat over het booten met een betrouwbare omgeving.
Elk onderdeel zou een password in de TPM kunnen stoppen die beschikbaar komt als aan voorwaarden voldaan is.
bv. De EFI-BIOS rekent een checksum uit over het bootloader en meld die aan de TPM
Als de EFI-BIOS in de checksum ook een beschrijving van de hardware meeneemt is ook hardware update vastgelegd.
En start de bootloader: de bootloader vraagt het password aan de TPM, en doet hetzelfde checksum uitrekenen en melden aan de TPM met de bootloader config, kernel, initramsfs etc. Het kernel bootscript zal een vergelijkbare truck uithalen en aan de TPM de decryptie sleutel voor encrypted disks opvragen,
schijven mount en het systeem verder opstarten. De kernel kan zich beschermen met het uitsluitend accepteren van correct ondertekende drivers etc. Het bootschript kan voor gebruik alle images verifieren inding vereist.
Als een van de onderdelen veranderd wordt zal de checksum ervan ook veranderen ==> de volgende stap krijgt geen password meer en kan alleen handmatig verder. (na invoering van het correcte wachtwoord).

Voor de checksum worden cryptografische methoden gebruikt zoals ook voor certificaten gebruikt worden, dus certificaten zijn dan ook het makelijke middel om deze betrouwbaar beschikbaar te stellen.

Zodra een tool met root access check checksums in TPM opnieuw kan vastleggen is er een issue.
Dus Operational security is van belang: geen root access zonder wachtwoord of andere verificatie. (dus NOOIT no-password sudo). 2FA oid is ook "handig"...
Als je een simpele omgeving er op na houd en altijd onder root werkt, dan wel sudo zonder wachtwoord gebruikt is je beveiligings niveau gewoon 0..., en vergelijkbaar met een windows Home edition.

Je omschrijft het trusted boot proces, dat zelf met een 15 jaar oude TPM uitgevoerd kan worden met een legacy BIOS. Het onderwerp hier is Secure Boot, dat iets anders is dat enkel met UEFI gedaan kan worden. Met Secure Boot verifieert de UEFI firmware de cryptografische handtekeningen van binary blobs voordat deze uitgevoerd worden, gebaseerd op een algemene CA+CRL combinatie (die van Microsoft). Daarnaast kan een fysieke gebruiker zelf het booten van specifieke binary blobs toestaan d.m.v. fysieke toegang, mits het in de UEFI configuratie is toegestaan (wat beschermd kan worden met een wachtwoord).

Secure Boot staat los van trusted boot, maar ze kunnen elkaar wel aanvullen. Secure Boot geeft beveiliging vanuit een derde partij (Microsoft/sleutelmateriaal van de gebruiker) tegen online malware aanvallen. Trusted boot geeft beveiliging vanuit het eigen systeem voor 'data at rest' door het verkrijgen van kritiek sleutelmateriaal een onderdeel te maken van een correct bootproces. Ze hebben wat overlap (beiden zijn afhankelijk van een zekere authenticiteit van binary blobs tijdens het boot proces), maar doen dat via andere aanvliegroutes.

[Reactie gewijzigd door The Zep Man op 30 juli 2020 21:42]

Urghh en met een geupdate Debian grub2 package geen boot meer:

Error: symbol `grub_calloc` not found.

Zal ongetwijfeld erg secure zijn .
Maar goed maar weer zien hoe we dit weer vlot getrokken krijgen, gelijk bij al m'n andere machines grub2 updates maar on hold gezet.

Leuk he Internet staat er vol mee, Ubuntu, Debian, ... De fix lijkt eenvoudig, maar kost wel weer tijd.

edit:
stappenplan:
1. download Debian live CD iso en zet met unetbootin op USB
2. mount root (sdXY) en boot (sdXZ) op /mnt/root resp /mnt/root/boot
3. sudo apt install grub2
4. sudo grub-install --root-directory /mnt root /dev/sdX
5. reboot

[Reactie gewijzigd door Rukapul op 30 juli 2020 21:49]

Mjah was gauw gevonden dat ik niet de enige was met dit probleem.
Heb zelf m'n Debian install medium gepakt en het via "rescue" optie gedaan, zal al met al onder de motorkap op hetzelfde neerkomen.
Maar goed was wel weer frustie voor zo'n in de meeste situaties niet echt belangrijke fix die wel een hoop gedoe veroorzaakt.

heeft daarvoor in ieder geval roottoegang tot een systeem nodig.

Is het nog wel een kwetsbaarheid als je root nodig hebt? Als een kwaadwillende root heeft heb je wel wat anders aan je hoofd lijkt me.

Niet helemaal waar.

Stel ik ben een aanvaller. Ik pak een stukje software, injecteer daar iets in wat misbruik maakt van dit gat en jij installeert dat. Jij hebt root toegang nodig om die installatie te doen, de injectie ziet er relatief ongevaarlijk uit maar toch kan ik nu dingen op jouw systeem doen.

De uitspraak dat de aanvaller root toegang nodig heeft is erg relatief.

Jawel, maar als root bereid is om onbetrouwbare code uit te voeren heb je natuurlijk al gewonnen. Dat er in grub een kwetsbaarheid zit maakt op dat moment niet uit -- met die root toegang kun je rechtstreeks alle data van alle gebruikers uitlezen en naar Rusland uploaden (bij wijze van), je hoeft dan niet nog eens apart grub te patchen. Zulke dingen moeten desondanks natuurlijk wel opgelost worden omdat boot loaders infecteren het moeilijker zo niet onmogelijk kunnen maken een gecompromitteerd systeem weer in het gareel te krijgen (aan de andere kant is geheel wissen & opnieuw beginnen de enige betrouwbare manier daarvoor, dus ja). Daarnaast is er altijd een kans dat een exploit door een slimme truc via-via alsnog uitgevoerd kan worden door een gebruiker met minder privileges; de software is tenslotte hoe dan ook verkeerd bezig.

Ja, grote aanvallen gebeuren regelmatig door een opeenstapeling van kleine, op het eerste zicht moeilijk combineerbare bugs. Het hangt ook af van wat de kwaadwillende wil bereiken.

Met een volledig correcte selinux policy kun je bijna alles als root uitvoeren zonder je systeem in gevaar te brengen. Ik denk alleen niet dat veel mensen hun hele computer met selinux beveiligen; er mist altijd wel hier en daar een regel voor programma's die je draait, dus zorg je dat je dingen niet zomaar als root uitvoert.

Een groot gedeelte van Secure Boot is bedoeld om rootkits tegen te gaan. Je zou het allerhoogste niveau binnen de kernel moeten hebben om tijdens het booten rootkits te injecteren. Als je dat kan verzekeren, weet je ook dat je antivirus zijn werk kan doen.

Ook kan malware zich verder nestelen als het tijdens het bootproces geladen wordt, omdat mitigaties zoals selinux en een goede IOMMU het moeilijker maken om zelfs als root nog kwaadaardige dingen te doen. Ik weet niet in wat voor mate realtime antivirus bestaat en gebruikt wordt op Linux, maar daar zal het verhaal niet heel anders zijn als het bestaat.

Samengevat: Secure Boot is gedeeltelijk ingericht om tegen een aanval van een aanvaller met root access te beschermen en de verspreiding van rootkits te voorkomen, ook al is dat niet de hele achtergrond ervan.

Daarnaast betekent root natuurlijk niet per se root op jouw installatie. Bij veel Linuxdistributies (zoals Ubuntu, Debian, Mint) laten /boot onversleuteld staan als je versleuteling aanzet. Iemand kan een evil maid attack uitvoeren om het grub.cfg-bestand aan te passen en dan te wachten tot je je wachtwoord afgeeft aan de bootloader die besmet is geraakt met een rootkit. Later wordt de computer helemaal gestolen en ontsleuteld met het wachtwoord dat met de evil maid attack is ontfutseld. Ook dat is een scenario waartegen een goede Secure Boot-implementatie zou moeten beschermen.

Het kan een tijdelijke root toegang (door een andere vulnerability) omzetten in stille permanente toegang. Simpel scenario: Via een andere exploit krijg je kort root toegang tot het filesystem maar niet veel meer dan dat. Je past de file aan, gooit een bootloader met malware op het systeem en crasht vervolgens het systeem zelf. De beheerder ziet een gecrasht systeem en doet een reboot... Presto, je hebt stille malware in het systeem hangen. Waar een virusscanner vaak geen zicht op heeft.

Prima methode voor (bedrijfs)spionagedoeleinden.

Grub wordt gebruikt voor multi-boot systemen. Dit is dus een escalatie. Root op 1 OS kan dus gebruikt worden om andere OS'en aan te vallen.

Is het nog wel een kwetsbaarheid als je root nodig hebt? Als een kwaadwillende root heeft heb je wel wat anders aan je hoofd lijkt me.

Dan zou heel secure boot overbodig zijn, toch?

Aan één kant heb je gelijk maar stel de kwetsbaarheid waarmee ik Root heb (of als ik ergens anders ga werken en geen admin meer ben bij de oude werkgever bijv) kan je hiermee een backdoor inbouwen voordat ik Root toegang verlies. Misschien niet de enige manier maar als je zorgt dat je zoveel mogelijk kwetsbaarheden inzet is de kans dat je toegang houd tot het systeem als hacker natuurlijk het grootst.

Ik begrijp wel dat RedHat zegt dat het allemaal wel meevalt, volgens mijn was/is de Linux community toch al tegen secure boot. Daarnaast kun je nu het systeem starten met je eigen usb stick, als je hard disk encrypt is dan is er nog niet veel aan de hand.. volgens mij kun je nu alleen een systeem stelen die een bios wachtwoord heeft en toch stiekem opstarten 🤣

Linux community is niet tegen secure boot per se, maar tegen het afsluiten van hardware door een fabrikant en dan van die ene fabrikant afhankelijk zijn voor een certificaat 'secure' (en dan nog niet echt heel veel meer veilig zijn)

Ik heb op mijn computers (behalve Apple) al een tijd alleen nog secure-boot-certificaten die ik zelf beheer, is die mogelijkheid bij nieuwere firmwares verwijderd? Dat zou ik wel kwalijk vinden....

Voor zover ik zie ben ik zolang ik alleen die certificaten laat accepteren in principe beschermd tegen deze aanval ( Tenzij mijn sleutel wordt gejat of ik nietsvermoedend een foutieve bootloader onderteken natuurlijk)

Het is altijd afhankelijk van het mobo geweest. Niet elk moederbord of apparaat geeft je de mogelijkheid je eigen certificaten te beheren.

Dit was ook waarom de Linux community hier zo tegen was, want op die apparaten is Microsoft over het algemeen de enige aanbieder van die certificaten.

OK, wist ik niet. Ik was nooit een mobo tegengekomen waar het niet kon (maar die ervaring stopte ~4 jaar geleden). Het was, in ieder geval in de beginjaren van SecureBoot volgens mij ook een harde eis dat het kon (tenzij het een gesloten apparaat was als een tablet e.d. meen ik)

Ik heb op mijn computers (behalve Apple) al een tijd alleen nog secure-boot-certificaten die ik zelf beheer

Dat is ook de enige manier waarop je daadwerkelijk secure boot hebt. Als je niet je eigen sleutels gebruikt is het geen secure boot, maar third party restricted boot. Het is een misvatting om dat als secure te zien.

Daarom had ik zwart scherm bij booten vanmorgen..

Moest gfx drivers opnieuw fixen, erg irritant.