Linux-dualboot kan problemen ondervinden na Windows-update

Een van de patches in de Patch Tuesday van Microsoft veroorzaakt problemen bij Linux-dualbootsystemen die zowel Windows als Linux draaien. Na de update krijgen diverse gebruikers de melding 'er is iets ernstig misgegaan'.

De update in kwestie dicht een twee jaar oude kwetsbaarheid in grub, een opensource bootloader die gebruikt wordt om veel Linux-apparaten op te starten, schrijft Ars Technica. De kwetsbaarheid laat hackers Secure Boot omzeilen, wat gebruikt wordt om te voorkomen dat apparaten malafide firmware of software laden tijdens het opstartproces. Vorige week werd de fout gedicht met de maandelijkse Patch Tuesday-update.

Niet lang daarna verschenen diverse meldingen van gebruikers die tegen problemen aanlopen. Dualbootapparaten die Secure Boot aan hebben staan, kunnen Linux niet langer opstarten, klagen gebruikers. Wie toch probeert om Linux te laden, krijgt de melding 'Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation'. Gebruikers melden dat verschillende Linux-distro's, zoals Debian, Ubuntu, Linux Mint, Zorin OS en Puppy Linux, door het probleem getroffen worden.

Advies Microsoft

Microsoft erkent zelf inmiddels ook dat de update dualbootsystemen raakt, ook al beloofde het bedrijf eerder in zijn securitybulletin dat dit niet het geval zou zijn. Het probleem ontstaat door een Secure Boot Advanced Targeting-instelling, waarmee oude, kwetsbare bootmanagers worden geblokkeerd. "Op sommige apparaten werden sommige aangepaste methodes voor dualbooting niet opgemerkt door de dualbootdetectie", aldus Microsoft. Op die apparaten werd de zogenoemde sbat-instelling wel toegevoegd, terwijl dat niet had moeten gebeuren.

Wie de installatie van de update van deze maand nog niet heeft afgerond door het apparaat te herstarten, wordt geadviseerd om een door Microsoft geleverde registersleutel te gebruiken, zodat de update niet geïnstalleerd wordt. De registersleutel kan weer verwijderd worden als er toekomstige sbat-updates verschijnen die wel geïnstalleerd moeten worden.

Microsoft heeft vooralsnog geen adviezen voor gebruikers die de installatie al wel hebben afgerond. Gebruikers hebben zelf wel een workaround gevonden, namelijk om de uitgerolde sbat te verwijderen. In een oudere post op het Ubuntu-forum wordt uitgelegd hoe dat moet. Een andere optie is om het EFI-paneel te openen en Secure Boot uit te schakelen, al gaat dat wel met mogelijke beveiligingsrisico's gepaard.

Reacties (62)

[verdroidnogaan2]

(Misschien is deze oplossing al gepost, maar zo te zien niet)

Ik vond online een makkelijke oplossing die voor mij goed werkte:

1. Schakel Secure Boot uit
2. Log in in Ubuntu (Mint) en open een terminal
3. Verwijder de SBAT policy dmv:
sudo mokutil --set-sbat-policy delete *
4. Reboot je pc en log weer in in Ubuntu (Mint) om de SBAT policy te updaten dmv:
sudo mokutil --set-sbat-policy latest *
5. Reboot en schakel Secure Boot weer in.

*Let op: voor "set" staan 2 streepjes.

[Reactie gewijzigd door verdroidnogaan2 op 22 augustus 2024 15:13]

[Magic Power]

sudo mokutil --set-sbat-policy delete *
sudo mokutil --set-sbat-policy latest *
*Let op: voor "set" staan 2 streepjes.

Voor de volledigheid, in deze regels is de laatste * dus geen onderdeel van het commando. gebruik dus de commando's
sudo mokutil --set-sbat-policy delete
en
sudo mokutil --set-sbat-policy latest

[verdroidnogaan2]

Thx. Ik dacht dit duidelijk gemaakt te hebben, maar jouw uitleg maakt ut volledig.

[rodgermoore]

Yup. Binnen 5 minuten was het probleem opgelost. Volgens deze post is je laatste commando niet nodig. Na de delete worden bij een reboot al nieuwe policies aangemaakt. https://askubuntu.com/que...security-policy-violation

[LongTimeAgo]

Dit werkt echt perfect! Dank je!

[michaelkamen]

Ja, ik had dit zelf opeens een paar dagen geleden.
Heb het opgelost door Secure Boot uit te zetten, zodat ik weer in Linux kon booten, en de SBAT policy te resetten. Daarna kon ik Secure Boot weer aanzetten en werkte Grub weer.
Helaas moest ik wel 2x de unlock code voor Bitlocker invoeren voordat ik weer in Windows kon...

[NaliXL]

Een van de patches in de Patch Tuesday van Microsoft...

De update in kwestie dicht een twee jaar oude kwetsbaarheid in grub

Nou breekt mijn klomp... Grub is toch geen Microsoft product, en word vrijwel exclusief vanuit linux en andere niet-windows geïnstalleerd/gewijzigd? Gaat Microsoft daar nu ongevraagd op eigen houtje aan zitten rommelen dan?

Waar zitten ze allemaal nog meer aan zonder dat je het door hebt?

[PolarBear]

Nou breekt mijn klomp... Grub is toch geen Microsoft product, en word vrijwel exclusief vanuit linux en andere niet-windows geïnstalleerd/gewijzigd? Gaat Microsoft daar nu ongevraagd op eigen houtje aan zitten rommelen dan?

Zie: https://msrc.microsoft.co...US/advisory/CVE-2022-2601

To address this security issue, Windows will apply a Secure Boot Advanced Targeting (SBAT) update to block vulnerable Linux boot loaders that could have an impact on Windows security. The SBAT value is not applied to dual-boot systems that boot both Windows and Linux and should not affect these systems. You might find that older Linux distribution ISOs will not boot. If this occurs, work with your Linux vendor to get an update.

en https://learn.microsoft.c...ndows-11-23h2#3377msgdesc

The August 2024 Windows security update applies a Secure Boot Advanced Targeting (SBAT) setting to devices that run Windows to block old, vulnerable boot managers. This SBAT update will not be applied to devices where dual booting is detected. On some devices, the dual-boot detection did not detect some customized methods of dual-booting and applied the SBAT value when it should not have been applied.

Door een bug worden dus wél dual-boot systemen geupdated maar dat zou niet moeten. Grub2 zelf wordt overigens niet aangepast.

Punt is dat deze kwetsbaarheid in Grub2 misbruikt kan worden om op een secure boot enabled Windows device. En dat is het gat wat Microsoft heeft gedicht met deze SBAT update.

SBAT is onderdeel van de EFI firmware. Zie meer hier: https://www.gnu.org/softw...t-Advanced-Targeting.html

[oef!]

Secure boot is een Microsoft ding bedoeld om Windows veilig te houden. Als MS een patch uitbrengt die een 2 jaar oude vuln in grub dicht dan vind ik dat niet onredelijk. Er wordt verder ook niets aangepast aan Linux zelf.

[Datastream]

Dus na al die jaren saboteert Microsoft nog steeds dualboot met linux. Goed om te zien dat die situatie niet veranderd is en mijn keuze voor compleet aparte drives de juiste is.

[The Zep Man]

Het ligt niet helemaal aan Microsoft:

Het probleem ontstaat door een Secure Boot Advanced Targeting-instelling, waarmee oude, kwetsbare bootmanagers worden geblokkeerd. "Op sommige apparaten werden sommige aangepaste methodes voor dualbooting niet opgemerkt door de dualbootdetectie", aldus Microsoft. Op die apparaten werd de zogenoemde sbat-instelling wel toegevoegd, terwijl dat niet had moeten gebeuren.

Ik weet dat van bepaalde oude apparaten (beetje de beginperiode van 2012-2015, maar ook sommige nieuwe moederborden) de Secure Boot-implementatie brak is. Bepaalde "gestandaardiseerde" methoden worden vanuit Linux niet ondersteund (ligt aan de firmwarekant, niet aan Linux). Ook heeft niet elke implementatie de functies om pre-boot sleutelmateriaal goed te beheren. Verder is er de mogelijkheid om je systeem te bricken als je zelf sleutelmateriaal gaat verwijderen als bepaalde blobs in de firmware ondertekend zijn (zoals die van Nvidia op bepaalde notebooks) en Secure Boot aan staat. Ergo, op sommige systemen is het risico van Secure Boot op beschikbaarheid van het systeem groter dan de risico's op vertrouwelijkheid en integriteit waartegen het zou moeten beschermen.

Hetzelfde zal het wel zijn met de dualbootdetectie van Microsoft, die niet goed kan omgaan met oude (brakke) UEFI-implementaties. Dat ontslaat Microsoft natuurlijk maar deels. Die had een dikke vinger in de pap bij het ontwerp van Secure Boot en bij implementaties (hun sleutelmateriaal wordt immers standaard meegeleverd op elke PC), en had daarbij meer robuustheid af kunnen dwingen.

[edit]
Voor gebruik van Secure Boot met Linux toets ik op oudere systemen of Linuxopdrachten om te werken met Machine Owner Keys verwachte resultaten geven. Zo heb ik een oud systeem waarbij het mogelijk is om vanuit (wat) UEFI (start) MOK sleutels/hashes toe te voegen aan het NVRAM, maar waarbij het onmogelijk is om deze waardes te verwijderen vanuit de firmware of vanuit Linux. In een dergelijke situatie kan je oud sleutelmateriaal niet verwijderen waardoor in theorie het NVRAM kan vollopen, en je weet daardoor dat de implementatie brak is met een verhoogde kans op andere, nog niet ontdekte bugs. Bij gebrek aan nieuwe firmware schakel ik op dergelijke systemen preventief Secure Boot uit.

[Reactie gewijzigd door The Zep Man op 23 augustus 2024 07:11]

[GertMenkel]

Het ligt een klein beetje aan Microsoft. Microsoft wilde dit probleem voorkomen door de beveiligingsupdate niet toe te passen bij mensen die dual booten, en die check werkte gewoon niet goed. Aan de andere kant ligt het probleem ook bij de Linux-distros die hun Grub niet goed bijgewerkt hebben.

In principe heeft Microsoft hier gelijk om hun eisen bij te stellen nadat er een bekend, lek openbaar gemaakt is en al lang opgelost is, maar ze hadden hun detectie toch wel beter kunnen testen als de opstartproblemen zo wijdverspreid zijn.

Voor de mensen die hier door zijn getroffen, zou ik Matthew Garrett (mjg59), toch wel een expert op het vlak als het om Linux-bootsecurity gaat, hierover willen quoten:

This is something that shouldn't have happened, and unless you're either Microsoft or a Linux distribution it's not your fault.

[84hannes]

In principe heeft Microsoft hier gelijk om hun eisen bij te stellen nadat er een bekend, lek openbaar gemaakt is en al lang opgelost

In principe is het raar dat je op een PC alleen een OS kunt draaien dat door Microsoft gesigned is, zelfs als je (uitsluitend) Linux draait. Natuurlijk is dat uit te zetten, maar dan is het weer niet veilig. Dat legt verantwoordelijkheid bij Microsoft.

[GertMenkel]

Zolang je PC voldoet aan de secure boot-standaarden, kun je je eigen sleutels inladen. Als je dat doet (en niet Microsoft's sleutels ook inlaadt) kan Windows ook helemaal niet meer opstarten (zonder óf je sleutels, óf het wachtwoord dat je op je BIOS instelt).

Het nadeel van je eigen sleutel gebruiken is dat de Linux-installer (en een eventueel herstelmedium) ook met die sleutel ondertekend moet zijn om deze op te kunnen starten. Microsoft heeft één sleutelset voor hun installers en bootloaders, maar Linux-distro's delen vaak de shim-bootloader (waar dit hele SBAT-verhaal vandaan komt).

Ik heb zelf mijn Linux-bootloaders niet handmatig ondertekend omdat mijn moederbordfabrikant, in haar oneindige wijsheid, een password recovery-functie heeft ingebouwd waarmee zo'n beetje elk proces zonder administratorrechten het BIOS-wachtwoord in plaintext kan uitlezen .

In de Linux-wereld zijn er niet veel partijen die ondertekende bootloader-images leveren. Ik geloof dat Red Hat hiermee bezig is in combinatie met UKI's; je kunt dan Red Hat's sleutels inladen en alle installers van hun distros starten, maar niet Ubuntu of Windows. Voor mensen die bijvoorbeeld RHEL gebruiken kan dit het proces veiliger maken zonder herstelmogelijkheden kwijt te raken.

[Reactie gewijzigd door GertMenkel op 22 augustus 2024 16:25]

[The Zep Man]

Zolang je PC voldoet aan de secure boot-standaarden, kun je je eigen sleutels inladen. Als je dat doet (en niet Microsoft's sleutels ook inlaadt) kan Windows ook helemaal niet meer opstarten (zonder óf je sleutels, óf het wachtwoord dat je op je BIOS instelt).

Wees voorzichtig met het verwijderen van sleutelmateriaal geleverd door de fabrikant van de PC. Sleutels van Microsoft verwijderen als je geen Windows draait en je eigen sleutels gebruikt is vaak prima, maar sleutels van de fabrikant verwijderen kan gevolgen hebben voor firmwareupdates (die je zelf moet ondertekenen). Ook kan het bepaalde systemen bricken als kritieke OpROM-code in de firmware blob ermee ondertekend is, zoals die voor embedded Nvidia videokaarten op Lenovo ThinkPads.

[GertMenkel]

Dat is waar, al is het ontzettend stom dat het überhaupt nodig is. Die bootloopende Thinkpads zijn verkeerd ontworpen en het is triest dat Lenovo hier nooit wat aan gedaan heeft.

[hooibergje]

oude apparaten (beetje de beginperiode van 2012-2015

Damn, en hier op werk hebben we nog computers van daarvoor (gelukkig niet alleen maar...).

[The Zep Man]

Damn, en hier op werk hebben we nog computers van daarvoor

Oudere computers ondersteunen geen Secure Boot, dus daar speelt dit probleem niet.

[Reactie gewijzigd door The Zep Man op 23 augustus 2024 07:06]

[GertMenkel]

Het probleem is dat distros hun Grub-versies niet bijwerken, of hun SBAT niet bijgewerkt hebben nadat ze Grub hadden bijgewerkt, nadat een lek in 2022 was opgelost.

Aparte drives gaan hier niet werken. Het gaat om een variabele op firmwareniveau.

[klakkie.57th]

Dan begrijp ik het niet zo goed blijkbaar. Een windows update die de firmware van mijn moederbord aanpast , of heb ik het nu nog niet begrepen ? Of wil je nu zeggen dat ik geen andere bootdik meer kan kiezen in mijn bios ??? Vragen vragen vragen

[GertMenkel]

Je moederbord bevat wat flashgeheugen met daarin dingen als de sleutels voor secure boot, een lijst van geïnstalleerde besturingssystemen, en andere instellingen. Als je dual boot, heeft je BIOS ook een lijst van bootopties, en dat is onderdeel van dat flashgeheugen.

Een onderdeel van die configuratie zijn wat variabelen voor secure boot met Linux. Normaal, volgens het model waarmee Secure Boot origineel ontworpen was, zou elke distromaker een bootloader aan Microsoft aanbieden, die getekend wordt en geboot kan worden. Dat is met de verscheidenheid van Linux niet realistisch (duizenden projecten zouden moeten worden gecheckt), dus is er een andere oplossing verzonnen: Microsoft ondertekent een vroege bootloader (ontwikkeld door Linuxontwikkelaars) die wordt geverifieerd door het moederbord (inclusief een lijst van ingetrokken certificaten etcetera), en die bootloader verifieert de volgende stap. Die verificatie is echter nutteloos als je een lekke bootloader op je bootpartitie kan zetten en exploiten.

Het punt van secure boot is dat rootkits niet het bootproces van Windows kunnen overnemen: alleen legitieme bootloaders mogen opstarten. Grub is legitiem, systemd-boot is legitiem, enzovoorts, maar je wilt niet dat iemand een legitieme versie van Grub kan gebruiken om een rootkit te schrijven. Daarom zit ook in Grub verificatie van de bootprocedure.

Echter zat er een kwetsbaarheid in Grub: zet een bepaald lettertype in de bootloadermap en je krijgt code execution. Omdat die versie van Grub ondertekend is, maar door iedereen gebruikt kan worden om het bootproces te manipuleren, is het nodig een retractie voor Grub uit te brengen: die versie van Grub is niet meer veilig.

Dit komt samen bij de zogenaamde SBAT die dit probleem veroorzaakt: dit is een UEFI-variabele waarin staat welke versies van welke applicaties veilig zijn. De update van Microsoft verhoogt de minimaal veilige versie van Grub naar de versie die gepatcht is. De shim-loader (het open source ding dat daadwerkelijk door Microsoft ondertekend is) kijkt in de SBAT of de Grub-versie die geladen wordt veilig is, ziet dat dit niet zo is, en weigert op te starten.

Door Grub te updaten naar een veilige versie, met een goede SBAT-handtekening om die update aan te geven, hadden Linux-distro's dit probleem kunnen voorkomen. Microsoft wilde ook alleen maar Windows-only-gebruikers beschermen, dus heeft ook een check ingebouwd (die niet goed genoeg was) om die beveiligingsconfiguratie niet toe te passen voor mensen die nog een oude, kwetsbare versie van Grub hadden. Aan de ene kant maakt dit het makkelijker voor rootkits om de beveiliging van Windows te omzeilen, maar aan de andere kant boot je Ubuntu 18.04 install of iets dergelijks nog wel gewoon; het is een afweging.

Dit is ook waarom de oplossing (als je niet wil/kan updaten) is "zet secure boot uit, herconfigureer de bootloader, zet secure boot aan". Linux zet de SBAT-variabele terug op wat nodig is om Grub op te starten en alles is weer zoals weleer. Een update van Grub/je OS zou ook werken, maar dat duurt langer dan de drie minuten die nodig zijn om de variabele terug te zetten.

[leecher]

Dit is de reden waarom de Windows en Linux installatie mijn systeem hun eigen drive en bootloader hebben. Schakelen tussen beide gaat via de bios. Tijdens het booten niks indrukken = Linux, een keertje F8 = Windows, op mijn Asus moederbord dan.

De howto: Eerst Windows installeren op een van de drives, boot flag van de Windows drive tijdelijk uitzetten, Linux installeren op drive 2, boot flag van Windows weer terugzetten.

[fverhoef]

Dit is ook hoe ik het doe, aangezien ik niet vaak in Windows iets doe.

Ik hoefde echter geen boot flags uit te zetten.

[johnbetonschaar]

Een andere optie (dit is wat ik gebruik) is alles altijd onder een hypervisor draaien, en dan een mechanisme om de hypervisor automatisch de juiste VM te laten opstarten (ik doe dat zelf via een bash scriptje dat een URL op mijn home-server queried, die URL wijst naar een PHP scriptje dat via een dropdown de VM kan kiezen/instellen of uitlezen wat de gekozen VM is).

Dit klinkt omslachtig maar als je toch al een servertje hebt draaien kost het alleen maar 2 simpele scriptjes. Voordelen zijn dat je op deze manier de juiste VM kunt configureren en booten via wake-on-lan (wat handig is als je de PC gebruikt voor remote streaming), en dat je zo veel VM's kan maken en booten als je maar wil en geen van de OS-en in de VM's daadwerkelijk aan je bootloader hoeven te komen. Je kunt in theorie zelfs meerdere VM's tegelijk booten.

Ik gebruik Linux/QEMU met GPU passthrough hiervoor en ik kan niet zeggen dat ik enig nadelig effect zie wat performance betreft, sterker nog ik heb de indruk dat mijn game VM beter presteert dan native omdat ik de vCPU's allemaal op dezelfde CCX van mijn 5950X kan pinnen

[Henk Poley]

Dat zou hierbij niet hebben geholpen. Er is een jaartje terug een zwakte ontdekt die het toeliet om met Secure Boot ingeschakeld toch niet-ondertekende code mee te laden. De bootloaders die dat toelaten worden nu geblokkerd.

Dus als jij van die oude bootloaders op je andere partities hebt, dan werken die niet met de nieuwe blokkades. In een ander commentaar hier wordt gemeld dat sommige niet kunnen updaten naar een nieuwe bootloader vanwege bugs in de UEFI (hoe dat zit weet ik niet).

Windows detetecteerde bij deze blokkade-update in principe of zo'n oude zwakke bootloader ergens geinstalleerd stond op zichtbare partities, en stelde de extra blokkades dan niet in, om het Linux systeem werkend te houden. Kennelijk ging die detectie soms mis, of hebben mensen die partitie (schijf) niet aangesloten, dus dan is het ook niet te controleren door Windows Update.

[leecher]

Ah ok. Dan heb ik deze update nog niet geinstalleerd blijkbaar want alles werkt nog

[Henk Poley]

Of je distro heeft gewoon de bootloader bijgewerkt naar een niet kwetsbare versie ergens in het afgelopen jaar. Er zijn (kennelijk) uitzonderingen waarbij een nieuwe bootloader en UEFI niet compatible zouden zijn, dan werd die update niet gedaan. Daar val je kennelijk niet onder.

[Tomatoman]

Dus na al die jaren saboteert Microsoft nog steeds dualboot met linux.

Saboteren is een doelbewuste, kwaadwillende actie. Er is niet wat erop wijst dat Microsoft met deze Windows update doelbewust en met kwade opzet probeert Linux uit te schakelen.

[wiseger]

Microsoft heeft een kwalijk tracking record t.o.v. Linux met haar jarenlange financiële steun aan SCO die met rechtszaken probeerde Linux kapot te krijgen. Zie Microsoft investeert in SCO

IBM bleek uiteindelijk via haar Novell patenten portefeuille de eigenaar van Unix te zijn en niet SCO. Waarna SCO al heel snel failliet ging, want er waren geen producten meer, alles draaide al een hele tijd alleen nog maar om het voeren van rechtszaken.

Vandaar mensen altijd met argusogen zullen kijken naar acties van Microsoft die Linux gebruikers in de weg zitten.

[PolarBear]

Microsoft heeft een kwalijk tracking record t.o.v. Linux met haar jarenlange financiële steun aan SCO die met rechtszaken probeerde Linux kapot te krijgen. Zie Microsoft investeert in SCO

Let wel, dit was 20 jaar geleden. En Microsoft kan nog van alles verkeerd doen, maar het is niet hetzelfde bedrijf als 20 jaar geleden. Microsoft is een grote contributor voor de Linux kernel, WSL heeft een duidelijke plek binnen Windows, Azure draait verschillende zaken op Linux etc etc.

[wiseger]

Grappig dat mijn reactie offtopic wordt gemodereerd en jou reactie op mij met plus twee.

Microsoft heeft na het SCO debacle en het succes van Azure het roer omgegooid en Linux server omarmd.

Linux op de desktop, mwah ik twijfel of die nu wel gewenst is door Microsoft. DirectX supoort voor Linux is nog ver weg.

[jerisson]

Ik zou het niet saboteren noemen, maar ik vind het wel vreemd dat Microsoft met Patch-Tuesday blijkbaar een aanpassing doet aan een onderdeel dat normaal gesproken niet door Windows maar door Linux beheerd wordt (GRUB).

Normaal gezien installeert Linux GRUB. Nu kan ik het mis hebben, maar in mijn ervaring wordt iedere update aan GRUB door Linux beheert: dus nieuwe versies van GRUB of nieuwe entries in het menu. Als je Windows wilt booten start GRUB de Windows boot manager op. Die boot manager wordt uiteraard wel beheerd door Microsoft/Windows.

Het statement

De update in kwestie dicht een twee jaar oude kwetsbaarheid in grub

Vind ik dan ook behoorlijk vreemd, daar dit een update aan GRUB impliceert, hetgeen ik niet zou verwachten.

En een update aan de Windows boot manager zou geen impact mogen hebben aan GRUB of de Linux-entries, tenzij de update naar een verkeerde lokatie op de schijf geplaatst wordt (en dus GRUB deels overschrijft - iets dat vroeger, bij de overgang naar GRUB2, voorviel als je Autodesk producten gebruikte...)

[MSalters]

Het probleem is dat een oude, unpatched Grub een exploit heeft die de Secure Boot chain van Windows breekt. Microsoft heeft die Grub versie destijds ondertekend (i.e. goedgekeurd als onderdeel van de WIndows Secure Boot chain), en revoked nu die handtekening.

[klakkie.57th]

Absoluut zo doe ik het ook aparte disks en gewoon andere bootdisk kiezen

[CAPSLOCK2000]

Het hele Secure Boot is imho nogal overschat. Het voorkomt niet zozeer dat je een "vreemd" OS of firmware wordt geladen, maar vooral dat je het achteraf kan controleren. Het is eigenlijk altijd al mogelijk geweest om er omheen te werken met je eigen bootable USB-stick. Het voorkomt niet dat anderen je computer opstarten met andere software en je HD uitlezen of software bij installeren.
Als iemand fysiek toegang tot je computer heeft dan kan die SB ook nog eens uitschakelen, of z'n eigen handtekening toevoegen aan de lijst van goedgekeurde signatures.
Dat is de detecteren maar daar heb je wel een stevige security-infrastructuur voor nodig die meeste mensen/organisaties niet hebben.

Het is niet dat SB helemaal geen waarde heeft, maar het is maar vrij beperkt in wat het nu echt doet. Ik slaap niet minder goed als ik het moet uitschakelen.

[Reactie gewijzigd door CAPSLOCK2000 op 22 augustus 2024 13:20]

[RobertMe]

Een deel van de "problemen" die je noemt heb ik nu niet het idee bij dat secure boot daar ooit voor bedoeld was. Het booten van een ander OS / via USB kun je naar ik aanneem voorkomen met een BIOS wachtwoord zodat je geen ander boot medium kunt opstarten.
Het aanpassen van bestanden / uitlezen van de HDD voorkom je met (full) drive encryption. Want als secure boot daar wel adequaat tegen beschermde was het nog niet goed, immers kon je de HDD nog steeds verwijderen.

Die laatste, full drive encryption, kun je weer wel koppelen aan secure boot. Zodat de HDD automatisch ontgrendeld wordt door de TPM. En ook dat zou waterdicht moeten zijn doordat de key in de TPM alleen uitgelezen kan worden door de bijbehorende executable. Dus een ander OS opstarten (al dan niet vanaf USB), ook al heeft dat andere OS nog steeds secure boot actief zal er nog steeds toe leiden dat de HDD niet ontsleuteld kan worden door de TPM. Been there, done that. Heb deze setup met Linux met FDE en TPM / secure boot. En met secure boot uit of een EFI executable die door een andere key is gesigned moet toch echt de recovery key gebruikt worden om de HDD te ontgrendelen.

En waar secure boot primair voor bedoelt is is het voorkomen van rootkits en dergelijke. Daarvoor werkt het AFAIK redelijk tot goed, zolang ze maar de private keys geheim houden. En nouja, dat schijnt dan weer niet perse het geval te zijn.

[CAPSLOCK2000]

[quote]
Een deel van de "problemen" die je noemt heb ik nu niet het idee bij dat secure boot daar ooit voor bedoeld was.
[quote]
Dat is een beetje mijn punt, mensen denken dat SB veel meer doet dan het in werkelijkheid doet.

full drive encryption (...) En ook dat zou waterdicht moeten zijn doordat de key in de TPM alleen uitgelezen kan worden door de bijbehorende executable.

Heb je daar misschien meer info over?
Hoe werkt die koppeling tussen TPM en executable?
Ik heb wel eens bitlocker schijven geopend onder Linux. De key uit TPM halen was wat gedoe maar wel mogelijk, misschien was dat nog met TPM1, dat durf ik niet meer te zeggen. Als ik snel even Google dan lijken er verschillende scriptjes te zijn die dat voor je kunnen doen, maar ik heb me er niet in verdiept.

En waar secure boot primair voor bedoelt is is het voorkomen van rootkits en dergelijke. Daarvoor werkt het AFAIK redelijk tot goed, zolang ze maar de private keys geheim houden. En nouja, dat schijnt dan weer niet perse het geval te zijn.

Ja, en imho is het een beetje inherent aan het model en het hele probleem. Private keys geheim houden die beschikbaar moeten zijn voor talloze bedrijven wereldwijd is erg lastig en haast niet uitvoerbaar. In theorie kun je gelekte sleutels blokkeren maar in praktijk is dat nog niet zo makkelijk, al is het maar omdat je in pratijk al snel miljoenen legitieme gebruikers raakt. In praktijk blijven veel van die uitgelekte sleutels gewoon werken waardoor het niet heel moeilijk is om er een in handen te krijgen voor het soort mensen/organisaties dat firmwarehacks kan maken.

Het helpt zeker, maar het is bepaald niet waterdicht. Geen probleem he, geen enkele beveiliging is waterdicht, het moet altijd deel zijn van een groter geheel.

[johnbetonschaar]

Het is eigenlijk altijd al mogelijk geweest om er omheen te werken met je eigen bootable USB-stick

Als je geen toegang hebt tot de BIOS en Secure Boot aanstaat kun je niet meer van een USB stick booten (of laat ik het zo zeggen: zo werkt het in ieder geval op computers en laptops waar ik bekend mee ben).

Edit: ik zie dat @RobertMe dit ook al had uitgelegd

[Reactie gewijzigd door johnbetonschaar op 22 augustus 2024 13:55]

[Blokker_1999]

Secure Boot heeft helemaal niet tot doel om te voorkomen dat een ander OS gestart kan worden. Wel dat heel het process vanaf de bootloader de integriteit van het systeem kan waarborgen, veel moeilijker maken voor malware om zich tijdens het opstarten van het OS reeds mee te laten laden.

En net zoals elke beveiligingslaag is er geen perfecte implementatie die alles tegen gaat.

Wil je voorkomen dat mensen opstarten vanaf een USB stick of het netwerk, dat mensen hun eigen keys toevoegen, dan vergrendel je je UEFI met een wachtwoord. Wil je voorkomen dat mensen andere hard drives in je systeem kunnen plaatsen, dan plaats je een slot op de kast.

[Guru Evi]

Wel, het moet ook in combinatie met andere systemen gebruikt worden zoals encryptie.

Dus als de sleutel niet kan ontzegeld worden werkt de encryptie niet, en dat is ook hoe oa. Bitlocker werkt. Je kunt zelf sleutels hebben die voor specifieke applicaties werken, dus als je niet kan ontzegelen, ondanks dat je misschien het OS wel geboot hebt kan vb. de webserver niet draaien, en daarnaast kun je ook attestatie vragen van het systeem (wat jij op bedoelt) waar je zelfs op afstand een vraagje stelt aan het systeem en als ie verkeert antwoord weet je dat er iemand mee aan het knutselen is, dus dat kun je laten deel uitmaken van oa. MFA, waar de gebruiker geen authenticatie kan uitvoeren zonder een verzegelde garantie van de firmware tot de applicatie.

Je kunt niet zomaar effe een USB stickje en je keys toevoegen, daar moet je eerst de boel voor ontzegelen en daar heb je de juiste sleutels voor nodig (als je natuurlijk alles goed ingesteld hebt met oa. systemd-cryptenroll op Linux of BitLocker) en je kunt dan misschien wel overschrijven (als je geen sleutel daarop hebt, wat veel bedrijven standaard tenminste een UEFI/BIOS paswoord hebben) maar dan vernietig je alle sleutels.

Nu zijn er over de jaren bepaalde sleutels gelekt of minder goed, oa van Microsoft en van Grub, dus moet je die sleutels uitsluiten. Dat moet dus via een firmware update EN een software update om dit zonder problemen te doen. Hier is waar Microsoft dus in de mist gaat, bij ons moeten we voor deze update uit te voeren het UEFI ontsleutelen met een key dat de computer (en natuurlijk Microsoft) niet heeft dus na deze update stop het systeem met booten met dezelfde fout alhoewel dit niet dual-boot systemen zijn.

Er zijn ook 3rd party encryptiesystemen, recoverypartities, boot managers die allemaal oude sleutels (kunnen) gebruiken en moeten herzegeld worden met de nieuwe sleutels dia (oa) Microsoft maar ook Dell en HP via firmware updates kunnen/moeten vervangen zoniet krijg je problemen zoals deze of BitLocker die niet meer werkt etc. Wij hebben een automatische installer voor SCCM, die moet nu ook vervangen worden met een nieuwe build.

[Reactie gewijzigd door Guru Evi op 22 augustus 2024 15:33]

[Zidane007nl]

Hier dit probleem nog niet ervaren op mijn Windows 10 met Linux Mint 22 dual boot. Vorige week maandag pas opgezet zodat ik hopelijk grotendeels van Windows af kan.

[markwiering]

Gebruikers melden dat verschillende Linux-distro's, zoals Debian, Ubuntu, Linux Mint, Zorin OS en Puppy Linux, door het probleem getroffen worden.

Oh, wordt dat nog steeds gebruikt?
Ik weet nog dat Puppy Linux in het verleden actief werd onderhouden, met nieuwe versies, bijwerkingen, programma's die beschikbaar werden gesteld voor Puppy Linux in de vorm van .pet bestanden en een uiterst actief forum. Dat was in 2013 en 2014. Er was zelfs een Windows-installeerder voor Puppy Linux. Gewoon vanuit Windows XP de installeerder draaien en jij kun meteen opstarten met Puppy Linux.

Daarna is Puppy Linux een beetje doodgevallen, merkte ik. De hoofdpagina van Puppy Linux verdween. Het forum waar Puppy Linux op zat verhuisde naar een ander domein (wat maanden in beslag nam) en er werden daarna minder nieuwe versies uitgerold. Er was één gebruiker (met '666' in de gebruikersnaam) die nog wel een paar keer was gekomen met een nieuwe versie van Puppy Linux, maar die versies intoduceerden visuele inconsistenties (menuknoppen die dwars door elkaar heen liepen als jij een ander thema opzette) en problemen met de toetsenbordindeling. Jij kon niet meer "VS internationaal met dode toetsen + Russisch" hebben; alleen "VS internationaal met dode toetsen" of "VS (zonder dode toetsen) + Russisch". Problemen die Puppy Linux in het verleden nooit had kwamen nu wel op.

Door alle ellende die in 2016/2017 speelden had ik besloten om dan maar gewoon te blijven zitten op Puppy Linux Tahrpup (uit 2014), omdat die versie van Puppy Linux het goed deed, uitstekend presteerde en niet geplaagd werd door de fouten die wel zaten in latere versies van Puppy Linux.

Toen ik ging studeren op de UvA (Informatica) kon ik Puppy Linux niet normaal werkend krijgen op mijn nieuwe schootcomputer. Zowel Tahrpup als de nieuwste versie van Puppy Linux hadden visuele problemen, zoals de muis die niet zichtbaar was of de beeldschermresolutie die belachelijk hoog was en waarbij het systeem vastliep als ik hem lager probeerde in te stellen.

Toen was ik dus overgestapt op Ubuntu (later Kali Linux, daarna MX Linux), maar op mijn computer uit 2003 draait nog steeds Puppy Linux Tahrpup. Echt een prachtsysteem!

Maar, ik dacht dus dat Puppy Linux een beetje verleden tijd was. Maar, als ik https://puppylinux-woof-ce.github.io/ bekijk, zie ik dat de laatste versie van Puppy Linux verenigbaar is met Debian 12, de recentste versie van Debian. Dat betekent dus dat Puppy Linux nog steeds in de race is!

Gaaf! Ik ga de nieuwste versie van Puppy Linux uitproberen in een virtuele machine!

[HollowGamer]

Jullie hadden niet een titel kunnen kiezen als: 'Linux-dualboot met oudere Secure Boot kunnen mogelijk niet meer booten na laatste Windows-update'.

Ik heb zelf Secure Boot, maar het blijft zo vaag dat MS zich hiermee heeft bemoeid. Het is echt voor sommige een hell iets anders te draaien (NVIDIA bijvoorbeeld), omdat MS enkel om Windows geeft. Daarom schakelen velen het weer uit, maar dat is niet zo heel veilig, aangezien het wel degelijk iets bijdraagt aan de beveiliging van het OS.

Beste zou zijn dat er echt worden gekeken naar UEFI in het algemeen, misschien moet Coreboot maar een standaard gaan worden.

[MrFax]

Bij Ubuntu kan je Secure Boot na de registersleutel te hebben toegevoegd zoals ik het begrijp gewoon weer aanzetten. (Enable Secure Boot->Restore Factory Keys) Canoncial gebruikt een Microsoft-signed shim loader.

Bij andere distro's zal je wel zelf weer alles moeten instellen om Secure Boot weer werkend te krijgen.

[Reactie gewijzigd door MrFax op 22 augustus 2024 13:55]

[iDog]

Dat verklaart wel waarom ik gisteren bij een laptop waarop ik gewoon met de Linux Mint boot-usb wilde starten om wat dingen te testen hetzelfde zag, toen kreeg ik idd ook " 'Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation'"

Dacht dat een bios instelling was, de laptop stond al een paar weken uit, dus kan dan toch niet aan de deze patch liggen ?

edit :

[...]


Als je geen toegang hebt tot de BIOS en Secure Boot aanstaat kun je niet meer van een USB stick booten (of laat ik het zo zeggen: zo werkt het in ieder geval op computers en laptops waar ik bekend mee ben).

Ah, dus gewoon secure boot uitzetten en dan was het geen probleem geweest. Got it.

[Reactie gewijzigd door iDog op 22 augustus 2024 15:25]

[Hobbit13]

Boot van een Linux Live OS op m'n Surface Pro 7 wil hier ook niet meer. Maar de update lijkt meer in de war geschopt te hebben, ik kom de Bios ook niet meer in Wordt dus lastig om Secure Boot uit te zetten.