Dit soort situaties is precies waarom je bij de introductie van secure boot zoveel negatieve geluiden uit de FOSS hoek kwamen. Het is natuurlijk van de gekke dat MS wel even kan bepalen of anderen iets moeten updaten, en dat andere afhankelijk zijn van de goodwill van MS om te zorgen dat ze kunnen (blijven) booten. Alsof MS de autoriteit is op het gebied van secure booten ;-)

" Alsof MS de autoriteit is op het gebied van secure booten ;-)"

In het land der blinden, is een oog koning. En pak dan die macht nog maar eens af.
Open source is een hartstikke positief uitgangsprincipe, maar de realiteit is dat het soms alsnog gewoon een bende is; en daar waar geld regeert, zijn organisaties al helemaal niet bereid te investeren in (de kwaliteit / verbetering van) 'gratis spul', zeker niet als de concurrent(en) daar mogelijk ook hun voordeel mee doen; hoe kortzichtig dat dan ook wel of niet is ...

https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#bkmk_timing

Ik vind het doodeng. Ik ga nog liever mijn BIOS updaten met een 3 1/2" floppy zoals dat vroeger ging. Die floppy kan je tenminste goed testen voor je naar de firmware schrijft. Ik voel dat ik hier helemaal geen controle over heb.

TS

P.S. KB5034441 komt nog steeds met een Download error - 0x80070643. Deze moet ook een Secure Boot update krijgen om te kunnen werken maar mijn partitie is te klein om de update te kunnen bevatten. Misschien denkt Microsoft dat het vanzelf een keertje lukt als je maar vaak genoeg probeert.

Hallo, hier TS,

Ik ben tot de ontdekking gekomen dat er bij Ubuntu updates voor Secure Boot zijn gekomen voor Mantic Minotaur en Noble Numbat: https://packages.ubuntu.com/noble/shim-signed -> Ubuntu Changelog:

Debian Sid lijkt echter tijdelijk gestopt te zijn met Secure Boot, de laatste changelog is:

De melding dat ze geen secureboot-db hebben is onheilspellend. shim-signed voor Ubuntu wordt onderhouden door Canonical zelf, dus dat zit wel goed. Dit geldt waarschijnlijk ook voor Linux Mint.

Ik zag bij Ubuntu dat er twee signed shims zijn in de shim-signed package. Dus eentje ondertekend met Microsoft Windows Production PCA 2011 (deze gaat over een half jaar verdwijnen door toedoen van Microsoft). En eentje ondertekend met Windows UEFI CA 2023 vermoed ik.

Het is mij niet helemaal duidelijk of Microsoft aparte sleutels gebruikt voor het ondertekenen van Windows en het ondertekenen van Linux en andere third parties.

TS

Volgens mij wel, maar dat was al genoemd in de voorgaande thread over dit onderwerp.

Bijvoorbeeld
https://techcommunity.microsoft.com/t5/windows-it-pro-blog/updating-microsoft-secure-boot-keys/ba-p/4055324

hieruit

en

Vrij duidelijk dus dat ze een aparte CA gebruiken voor het signen van third-party OS loaders.

Deze link is helemaal achterhaald sinds een week geleden. Er is op patchdinsdag echt heel veel veranderd. En de informatie die er in staat moet ook ergens anders officieel aanwezig zijn op de site van microsoft.

Ik kom uit op https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-10
Omdat Microsoft Windows Production CA 2011 en Windows UEFI CA 2023 verplicht zijn voor alle windows computers, worden deze gebruik door linux om de shim te ondertekenen.

Microsoft Corporation UEFI CA 2011 en Microsoft UEFI CA 2023 zijn niet verplicht door Microsoft en daardoor minder geschikt voor linux (omdat linux dan niet op alle PC's zou kunnen draaien).

De KEK keys zijn helemaal off-limit voor linux omdat daarmee de db en dbx databases gemanipuleerd kunnen worden. Als die lekken dan is het game over voor Microsoft en Secure Boot. Een aanvaller kan daarin dan zetten wat die wilt.

Ik beantwoord hiermee ook eigenlijk mijn eigen vraag al.

TS

P.S. Ik vind de naamgeving van Microsoft voor de db sleutels heel onduidelijk.

Hallo, hier TS,

Er zit een nog niet opgeloste bug in Ubuntu 24.04 LTS waarbij je computer niet meer opstart. https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/2061551. Dit vindt plaats bij een Asus Tablet met Windows 10 en een Intel Atom processor.

Het probleem lijkt op het probleem met de MOK table in shim-signed 1.48

Het lijkt erop, als je de LP's leest, dat de 64 kB ruimte voor Secure Boot sleutels op het moederbord vol raakt. Omdat Microsoft deze sleutels vast kan zetten in dit geheugen, kan dit tot problemen leiden. Zelf heb ik een Asus moederbord, maar dan een OEM voor AMD dus ik hoop dat deze dit probleem niet heeft.

Ik ben wel bang om Xubuntu 24.04 LTS nog te booten op mijn machine. Ook omdat er nog geen oplossing voor is en ik dus opnieuw een moederbord kan kopen met te veel fabrikant sleutels erop of gewoon te weinig geheugen voor de plannen van Microsoft en Canonical.

Als je geheugen ergens vol loopt (wat hier het geval lijkt) dan krijg je allerlei onvoorspelbare problemen. Minix (de voorloper van Linux) ging dan willekeurig processen killen om een voorbeeld te geven. Als je harde schijf vol loopt kan er ook van alles mis gaan. Je wilt dus absoluut voorkomen dat dit gebeurt.

Nog een voorbeeld van wat voor een ramp Secure Boot is geworden en dit was allemaal te voorzien.

TS

Goed nieuws! De definitieve blokkade van Windows Production PCA 2011 in de DBX van je moederbord is nu uitgesteld naar januari 2025 of later. Dit was oktober dit jaar. Dit betekent dat linuxen meer tijd hebben om hun bootmedia geschikt te maken voor Windows UEFI CA 2023.

Verder zijn er ook veel andere wijzigingen. Zie https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d.

Misschien komt van uitstel zelfs afstel (dat zou mooi zijn).

TS

FOSS heeft geen oplossing....

Microsoft wel, met TPM en keys in UEFI ben je gegarandeerd malware free in je bootsequence (anders boot ie niet)

De enige alternatieven met secure boot zijn Google producten (telefoons , tablets)

Of je moet gaan klooien met Coreboot, Dasharo en plugins zoals HEADS, wat maar op een paar moederborden werkt... Als je wil klooien met eeprom programmers that is...

Welke andere oplossing is er?

Microsoft en Google bieden verified boot, en FOSS loopt jaren achter (sinds 2017 ongeveer)

Als Secure Boot zo veilig is, waarom moeten dan de encryptie sleutels hiervan worden vervangen?

Vroeger had je een real-time virusscanner ter preventie, en een rootkit scanner voor detectie. Malwarebytes Anti-Malware heeft nog steeds een rootkit scanner die ik wekelijks gebruik op een MBR partitie.

TS

Het is duidelijk dat je niet voor ogen heb dat de rootkit al actief kan zijn voordat jij met mailware bytes kan scannen. Kortom.... dat wordt hem dus niet... Met MBR had je dat niet als je boot vanaf een bootable device, maar met de UEFI is dat anders...

Verified Boot controleert je bootsector en kernel voordat deze geladen worden... Daarom is antivirus in ring2 overbodig

Antivirus checkt achteraf...

Dat is een fundamenteel andere aanpak

Linux heeft hiervoor geen oplossing...


Windows heeft dit sinds ca 2017 als reactie op de vele cryptolockers toen. Nu zie je alleen cryptolocker infecties bij mensen die hun Windows niet hebben gesealed met Verified Boot in de TPM na installatie.... Dus je kunt stellen dat dit een heel goede oplossing was.

Als je een AV zou gebruiken bij bepaalde type malware, zou het kwaad al geschied zijn nog voordat je aan scannnen toekomt....
Bij de Verified Boot methode zie je dan een error, zodat je op tijd je harddisk content kunt redden voordat deze AES versleuteld is door criminalski software.

Maar als Secure Boot zo veilig is, waarom moeten alle cryptografische sleutels dan vervangen worden door Microsoft?

Wat ik zie is een hoop ongemak bij gebruikers van andere systemen als Windows en een extra aanvalsoppervlak door de buggy code die Secure Boot implementeert. Is het het waard dat je een theoretische beveiligingslaag hebt toegevoegd?

Misschien zijn de ransomware bendes zich gaan richten op servers van grote instanties in plaats van op burgers. Dat is ook een mogelijke verklaring. Als alles in de cloud zit, waarom zou je dan nog burgers aanvallen met ransomware? Val meteen de cloud aan voor een veel groter effect.

TS

Debian begon met het controleren van digitaal ondertekende checksums van geïnstalleerde bestanden (binaries, scripts en configuratie) 20 jaar voor secure boot werd geïntroduceerd. Wat dan wel weer jammer is dat ze voor die checksums nog steeds MD5 gebruiken, wat prima is om lees- en schrijffouten op te vangen maar niet meer voor gerichte aanvallen. Wet van de remmende voorsprong, maar ze liepen wel 20 jaar voor op Microsoft.

Nee, er wordt niet op malware maar op digitale handtekeningen gecontroleerd. Als een leverancier zelf gecompromitteerd raakt en er malware in ondertekende bootsequence-binaries belandt dan worden die vrolijk uitgevoerd.

Ook is de bootsequence lang niet alles. Het is niet voor niets dat je nog steeds antivirussoftware op Windows nodig hebt, terwijl dat op een goede Linux-distro praktisch gesproken typisch geen donder toevoegt. De belangrijkste beveiligingsmaatregel is dat het een distributie is: een gecontroleerde verzameling op elkaar afgestemde software die je uit maar een of enkele bronnen haalt. Dat verkleint de kans op ellende substantieel. Al geeft het net als secure boot geen 100% garantie, het werkt in de praktijk heel goed.

Er is iets grappigs met die boot sequence. Wist je dat de term BIOS (Basic Input/Output System) van CP/M afkomstig is, en daar niet iets in een geheugenchip op het moederbord was maar gewoon een onderdeel van het besturingssysteem dat (toen typisch) van een floppy werd geladen? Het is de IBM-pc geweest waar de BIOS naar een geheugenchip op het moederbord verhuisde, eerst ROM (die je uit de socket kon wippen om hem te vervangen), toen EPROM, later flash.

Het kan dus anders, en het gebeurt ook nog steeds. Bij de Raspberry Pi zit er geen BIOS op het moederbord, daar moet de eerste partitie op het micro-sd-kaartje (even uit mijn hoofd) FAT32 zijn, en daarop staat een generiek bestand met bootcode dat wordt geladen, en een hele reeks modelspecifieke bestanden waarvan de juiste daarna wordt geladen.

De eerste floppy disks zijn door IBM ontwikkeld, voor mainframes. Die dienden om tijdens het booten de microcode van de processoren te laden, de instructieset van de processoren werd dus van floppy geladen tijdens het opstarten. Dat zegt iets over hoe weinig er in de hardware zelf moet zitten om toch te kunnen starten. In een latere ontwikkeling kreeg je mainframes waar een laptop in zat die het bootproces aanstuurde. En voor de duidelijkheid: dat zijn uitermate betrouwbare systemen. Iets te, misschien, malware is (met zeer grote moeite) mogelijk, en de kans erop wordt vergroot omdat veel gebruikers ervan denken dat dat toch niet lukt.

De grap is dat je prima computers kan hebben zonder BIOS/UEFI-code op het moederbord, maar niet meer dan het minimum om iets te kunnen laden om verder mee op te starten. Dat minimum hoeft maar heel basaal en niet overschrijfbaar te zijn, zodat het moederbord zelf niet aangetast kan worden door malware. De rest van de code staat op een extern opslagmedium, en dat laat zich altijd controleren met code die weer van een ander opslagmedium komt.

Op basis daarvan zijn wel degelijk ook robuuste oplossingen te maken.

Jaren voor juist, tientallen zelfs, met bij Debian wel weer de wet van de remmende voorsprong. In hoe dat bij RedHat en SuSe zit heb ik me nooit verdiept.

Maar hoe dan ook, besef dat secure boot vooral nodig is omdat het OS kennelijk toestaat dat het bootproces wordt aangepast. Kennelijk wordt niet die zwakte zelf maar een consequentie ervan aangepakt. Je kan je dan afvragen of secure boot niet een pleister op de verkeerde plaats is.

Er zijn vast wel weer aanmerkingen te maken op hoe ik het nu neerzet, maar het punt is dat er niet maar één manier is waarop je robuuste systemen kan maken, er zijn ook andere benaderingen mogelijk. Een fundamenteel bezwaar dat ik heb tegen secure boot is dat het een leverancier in een machtspositie plaatst ten opzichte van andere leveranciers. Microsoft heeft die machtspositie nooit misbruikt, maar de hele situatie zou niet moeten bestaan, en er zijn wel degelijk alternatieven voor mogelijk. Denk niet alleen aan wat nu de dominante opzet is, denk ook aan wat er kan.