Inget konstigt, noll drama ... Men en annan har upptäckts sårbarhet, CVE-2020-10713, vilket påverkar GRUB2-startladdaren och Secure Boot. En publikation av forskargruppen Eclypsium är den som har stått bakom denna upptäckt och som de har döpt som BootHole. Även Microsoft har publicerat en post på sin säkerhetsportal och varnar för den och hävdar att det finns en komplicerad lösning just nu.
BootHole Det är en buffertöverskridande sårbarhet som påverkar miljarder enheter med GRUB2 och till och med andra utan GRUB2 som använder Secure Boot som Windows. I CVSS-systemklassificeringen har den fått 8.2 av 10, vilket innebär att det är hög risk. Och är att en angripare kan dra nytta av detta för att kunna utföra godtycklig kod (inklusive skadlig kod) som införs under startprocessen, även om Secure Boot är aktiverat.
så dispositivos nätverk, servrar, arbetsstationer, stationära datorer och bärbara datorer, liksom andra enheter som SBC, vissa mobila enheter, IoT-enheter, etc., skulle påverkas.
Enligt Eclypsium kommer det dessutom att vara komplicerat att mildra och det tar tid att hitta en lösning. Det kommer att kräva en djupgående granskning av bootloaders och leverantörer bör släppa nya versioner av bootloaders signerade av UEFI CA. Det krävs samordnade insatser mellan utvecklare i Microsofts öppna källkod och samarbetsgrupp och andra berörda systemägare för att få ner BootHole.
De har faktiskt gjort en uppgiftslista för att kunna fixa BootHole i GRUB2 och du behöver:
- Patch för att uppdatera GRUB2 och eliminera sårbarheten.
- Att utvecklarna av Linux-distributioner och andra leverantörer släpper uppdateringarna för sina användare. Både på GRUB2-nivå, installatörer och shims.
- De nya shims måste undertecknas av Microsoft UEFI CA för tredje part.
- Administratörer av operativsystem måste uppenbarligen uppdatera. Men det måste innehålla både det installerade systemet, installationsbilder och även återställning eller startbara media som de har skapat.
- UEFI-återkallningslistan (dbx) måste också uppdateras i firmware för varje drabbat system för att förhindra exekvering av kod under start.
Det värsta är att när det gäller firmware måste du vara försiktig så att du inte får problem och att datorerna stannar i tegel-läge.
För närvarande kan företag som Red Hat, HP, Debian, SUSE, Canonical, Oracle, Microsoft, VMWare, Citrix, UEFI Security Response Team och OEM, samt mjukvaruleverantörer, de arbetar redan för att lösa det. Vi måste dock vänta med att se de första korrigeringsfilerna.
UPPDATERING
Men att underskatta utvecklarnas och samhällets effektivitet skulle vara dumt. Redan det finns flera patchkandidater för att mildra det som kommer från företag som Red Hat, Canonical, etc. De har flaggat det här problemet som högsta prioritet och det lönar sig.
Problemet? Problemet är att dessa korrigeringar orsakar ytterligare problem. Det påminner mig om vad som hände med Metldown- och Spectre-lapparna, att ibland är botemedlet värre än sjukdomen ...