MSI:s moderkort uppges ha säkerhetsbrist i UEFI

Inte för att jag kör Secure Boot, men det ska ju fungera! Har inte många moderkort från MSI, men har åtminstone ett i en av datorerna.

Nu vet vi inte hur kontaktförsöken med MSI sett ut och om ansvariga faktiskt fått kännedom om bristen. Men man kan önska att tillverkaren ser till att agera, implementera en fix, och sen gå ut med info om det.

Får man däremot ingen respons från tillverkaren trots idoga fungerar det ju oftast att gå ut i media med det istället.

Jag köpte ett MSI-mobo till senaste burken men blev så osams med UEFI att jag nästan bytte ut det. Har förträngt detaljerna men vill minnas att jag inte lyckades få skräpet att följa den boot-ordning jag önskade hur jag än försökte.

Har skytt att gå in i UEFI igen som pesten men måste väl in och kolla hur det ser ut nu.

Ja.

Om du slår på "secure boot" så är standardinställningen att kolla att signaturen stämmer, och sedan skita i om signaturvalideringen misslyckas och köra på ändå oavsett.

Intressant. Har MSI moderkort som verkar vara påverkat. Får väl ställa om inställningarna manuellt då istället för att köra med standardinställningarna när jag ska köra secure boot. Klantigt av MSI. Förhoppningsvis fixar de standardinställningen i kommande BIOS-versioner.

Åtminstone i mitt fall kom det stödet då (eftersom de uppdaterade för att Win 11 skulle funka), så det är väl inte så konstigt.

Misstänker att deras fokus har varit att låta folk uppgradera till Win 11 utan att för den skull förstöra möjligheten att boota något äldre. Då vill man ha det så här. Personligen tycker jag väl att det logiska är att om Secure Boot är på så skall den per default blockera boot, men jag fattar var de kommer ifrån.

Gör en feature av det.
Secure Boot: ON / OFF / BYPASS

Nej. Har du secure boot på så failar den inte ifall valideringen misslyckas. Samma säkerhetsnivå som att secure boot är avstängd. Vilket är mycket värre då man tror att man satt på det.

Den listan verkar innehålla nästan alla MSI moderkort, hittade mitt X299 moderkort där. Får se om det kommer några bios uppdatering på detta.

Lite knepigt att det ens finns en sådan inställning ur ett rent säkerhetsperspektiv... Vem som helst kan ju gå in i UEFI på 99.999% av alla privatägda datorer (typ hamra F2 eller Delete oftast) och bara stänga av funktionen utan några som helst hinder. Sällan det är något lösenord inlagt, och iallafall förr i tiden glömdes ju lösenordet helt om man nollställde klockchippet. Kanske saker är modernare nuförtiden, har inte kollat uppriktigt sagt.

Förvisso krävs det ju direktåtkomst till datorn, och det brukar ju vara så att om skurken har tillgång till din apparat så är du sannolikt körd oavsett vad för åtgärder som utförs, men här kan det ju bli en okänd fälla. Du kan tro att secure boot är aktivt och att du är trygg, och så är det inte så.

Kör man windows 11 så tar det kanske stopp, jag har inte kollat upp exakt hur benhårt MS håller på att secure boot måste vara påslaget för att den ska starta upp, men det är nog tuffare än med typ linux, där man ju kan riva ut säkerhetskoden och kompilera om kärnan utan...

"I have tried contacting them like 5-6 times through different methods, but they are ignoring me." (från https://github.com/Foxboron/sbctl/issues/181#issuecomment-138... ) låter ju tyvärr inte jättelovande.

Separat från det såg jag även "BleepingComputer has contacted MSI to request a comment on the above and whether they plan to change the default setting via a new update, but we are still waiting to receive a response." (från https://www.bleepingcomputer.com/news/security/msi-accidental... ), så det får väl räknas som ett ytterligare kontaktförsök.

Är väl rätt sannolikt att ingen som förstår problemet fått se något av dessa kontaktförsök, vilket i så fall i sig är alarmerande.

Dock känner ju jag att det här med "... accidentally breaks ..." som Bleeping Computer tolkar det eventuellt är något optimistiskt.
Jag är ju lite rädd att det istället är någon bestämt att det är den optimala funktionen för "kompatibilitet", att både signalera att Secure Boot är "på" (så att t.ex. Windows 11 inte klagar) och samtidigt inte göra själva verifieringen (så att det inte uppstår några "problem").

MSI har svarat:
https://wccftech.com/msi-responds-to-faulty-secure-boot-imple...

Åh nej, då var det precis så illa som jag befarade...
Dvs:

För svaret som citeras i den artikeln säger:

"We preemptively set Secure Boot as Enabled and "Always Execute" as the default setting to offer a user-friendly environment that allows multiple end-users flexibility to build their PC systems with thousands (or more) of components that included their built-in option ROM, including OS images, resulting in higher compatibility configurations. For users who are highly concerned about security, they can still set “Image Execution Policy” as "Deny Execute" or other options manually to meet their security needs."

Jag skulle säga att det är MSI som gjort det riktigt korkade i det här läget, om det nu inte var Microsoft som rekommenderade den här obegripliga implementationen som MSI nu kör som standard.

Jag hade förväntat mig att man bara skulle ha två alternativ med secure boot. Med det aktiverat så avkrypterar den bootdisken via TPM och bootar. Inaktiverat så känner TPM att secure boot stängts av och man behöver mata in krypteringsnyckeln för att boota. Men det här mellanläget innebär att den bootar ändå trots att det går att boota osignerade binärer exempelvis på USB. Så helt klart en inställning man inte vill ska finnas om man vill kunna lita på secure boot.

Jag förstår inte riktigt problemet här. Det är inställningar för att konfigurera systemet och krävs för att kunna boota en del andra OS (vissa Linux-distros exempelvis), och för att få de att fungera med secure boot. I Asus fall står det även uttryckligen i deras handbok över BIOS-inställningar (MSI verkar inte ha samma information, vilket iof är dåligt).

Så, det hela ser mest ut att handla om en massa dram över att moderkortstillverkarna inte utgår ifrån att användaren struntar i manualen, och bara tänker köra Windows.

Problemet är rent konkret:

De har en inställning som heter "Secure Boot: on" (detta är standardinställningen nu). Denna gör ingenting (ingenting alls!) rent funktionellt utöver att indikera att Secure Boot är på (till användaren, till mjukvara som kollar).

Sedan har de "Secure Boot: off" som gör samma sak, men indikerar att Secure Boot är av (till användaren, till mjukvara som kollar).

Och till slut: "Secure Boot: custom" där det går att "välja till" att Secure Boot ska verifiera att mjukvaran som kör är signerad (dvs det Secure Boot betyder).

Dvs, det handlar inte om huruvida Secure Boot är på eller av som standard, eller liknande. Det handlar om att de har ett "Secure Boot: on" som är avsiktligt designat att vara direkt vilseledande och underminerar hela idén.

Fast det är ju så det måste funka:

Secure boot off: Helt avstängt - du kan inte göra något med secure boot.

Secure boot on: Du kan boota OS som kräver secure boot samt konfigurera secure boot med andra OS och nycklar. Verifierar inte att mjukvaran är signerad.

Secure boot custom: Gör det möjligt att verifiera att mjukvaran är signerad.

Kanske inte den bästa namngivningen men i grunden är det så det behöver funka.

Jag skulle tycka att vilket som av de här varianterna vore mycket mer okej om de inte gillar Secure Boot:

* "Secure Boot: off" som default
* Ett alternativ "Secure Boot: bypass" (eller vad de vill kalla det) med den här funktionen (t.o.m. som default om de verkligen måste), men att "Secure Boot: on" gör det som förväntas

Hursomhelst, det är iaf att de kallar det "on" (eller vad exakt de nu kallar det "enabled", "on", ...) som är vad hela uppståndelsen handlar om

Jag håller med om att man kunde namngivit det bättre. Däremot är det lite av en storm i ett vattenglas. Det borde inte vara en nyhet för någon som konfigurerat secure boot tidigare - ser ungefär likadant ut i alla BIOS.

Jag har moderkort som jag vet vägrar boota in i osignerat OS med "Secure Boot: on", så det är åtminstone inte konsekvent att "alla" gör så eller att det "måste" vara så.

Men uppenbart är det kanske så att vissa valt att implementera "on" som "signalera 'på', men gör inget", andra som "signalera 'på', verifiera utifrån Microsofts nycklar" (vilket väl fungerar för de vanligaste fallen som många använder, Windows + några större Linux distros).
Det kaoset är ju i sig illa, om det är så.

När du har satt "secure boot enabled" förmodar jag att du har något i stil med "custom" och "standard" som val sen? Det är så det sett ut på Asus och Gigabyte för mig. Default är sen "custom" som tillåter att man konfigurerar secure boot.

Nu minns jag inte exakt hur menyerna sett ut, men det kan stämma att det var något sådant i de fallen. Det finns ju absolut även inställningar att pillra på iaf.

I de exemplen jag minns så har ju iaf "på" verkligen varit på (därav att man minns det, är ju just situationer där man blivit tvungen att stänga av funktionen eller ändra inställningarna för att boota OS som inte är signerade med MS-nycklarna som i någon mån är minnesvärda).

Vore intressant (men förmodligen alldeles för jobbigt reda ut) att se vad det eventuellt står i specen att beteendet skall vara. Jag tycker att det verkar direkt osannolikt att det "ska" vara som MSI gjort.