Niets vreemds, nul drama's ... Maar er is een ander ontdekt kwetsbaarheid, CVE-2020-10713, die de GRUB2-bootloader en Secure Boot beïnvloedt Een publicatie van het Eclypsium-onderzoeksteam is degene die achter deze bevinding heeft gestaan en die ze hebben gedoopt als BootHole. Zelfs Microsoft heeft een bericht op zijn beveiligingsportaal gepubliceerd waarin het wordt gewaarschuwd en beweert dat er op dit moment een gecompliceerde oplossing is.
Bootgat Het is een kwetsbaarheid voor bufferoverloop die miljarden apparaten met GRUB2 treft en zelfs anderen zonder GRUB2 die Secure Boot gebruiken, zoals Windows. In de CVSS-systeemclassificatie is het gescoord als 8.2 op 10, wat betekent dat het een hoog risico is. En het is dat een aanvaller hiervan zou kunnen profiteren om willekeurige code (inclusief malware) die tijdens het opstartproces is geïntroduceerd, uit te voeren, zelfs als Secure Boot is ingeschakeld.
dus dispositivos netwerken, servers, werkstations, desktops en laptops, evenals andere apparaten zoals SBC's, bepaalde mobiele apparaten, IoT-apparaten, enz., zouden worden beïnvloed.
Bovendien, volgens Eclypsium, zal het zo zijn ingewikkeld om te verzachten en het zal even duren om een oplossing te vinden. Het vereist een grondige beoordeling van bootloaders en leveranciers moeten nieuwe versies van bootloaders uitbrengen die zijn ondertekend door UEFI CA. Er zijn gecoördineerde inspanningen nodig tussen ontwikkelaars in de open source- en samenwerkingsgemeenschap van Microsoft en andere getroffen systeemeigenaren om BootHole neer te halen.
In feite hebben ze een te doen lijst om BootHole in GRUB2 te kunnen repareren en je hebt nodig:
- Patch om GRUB2 bij te werken en de kwetsbaarheid te elimineren.
- Dat de ontwikkelaars van Linux-distributies en andere leveranciers de updates voor hun gebruikers vrijgeven. Zowel op het niveau van GRUB2, installateurs en shims.
- De nieuwe shims moeten worden ondertekend door de Microsoft UEFI CA voor derden.
- Beheerders van besturingssystemen zullen uiteraard moeten updaten. Maar het moet zowel het geïnstalleerde systeem, de installer-images als de herstel- of opstartmedia bevatten die ze hebben gemaakt.
- De UEFI Revocation List (dbx) moet ook worden bijgewerkt in de firmware van elk getroffen systeem om uitvoering van code tijdens het opstarten te voorkomen.
Het ergste is dat als het om de firmware gaat, je moet oppassen dat je geen problemen krijgt en dat de computers blijven in brick-modus.
Momenteel zijn bedrijven zoals Red Hat, HP, Debian, SUSE, Canonical, Oracle, Microsoft, VMWare, Citrix, UEFI Security Response Team en OEM's, evenals softwareleveranciers, ze werken er al aan om het op te lossen We zullen echter moeten wachten om de eerste patches te zien.
UPDATE
Maar het zou dom zijn om de effectiviteit van de ontwikkelaars en de gemeenschap te onderschatten. Nu al er zijn verschillende patchkandidaten om het te verzachten dat afkomstig is van bedrijven zoals Red Hat, Canonical, enz. Ze hebben dit probleem als een topprioriteit aangemerkt en het werpt zijn vruchten af.
Het probleem? Het probleem is dat deze patches voor extra problemen zorgen. Het doet me denken aan wat er is gebeurd met de Metldown- en Spectre-patches, dat de remedie soms erger is dan de ziekte ...