Nichts Seltsames, keine Dramen ... Aber ein anderes wurde entdeckt Sicherheitsanfälligkeit CVE-2020-10713, die den GRUB2-Bootloader und Secure Boot betrifft. Eine Veröffentlichung des Eclypsium-Forschungsteams ist diejenige, die hinter diesem Befund steckt und die sie als BootHole getauft haben. Sogar Microsoft hat auf seinem Sicherheitsportal einen Eintrag veröffentlicht, in dem darauf hingewiesen wird, dass es derzeit eine komplizierte Lösung gibt.
Stiefelloch Es handelt sich um eine Sicherheitsanfälligkeit bezüglich Pufferüberlauf, die Milliarden von Geräten mit GRUB2 und sogar andere Geräte ohne GRUB2 betrifft, die Secure Boot verwenden, z. B. Windows. In der CVSS-Systemklassifizierung wurde es mit 8.2 von 10 Punkten bewertet, was bedeutet, dass es ein hohes Risiko darstellt. Und es ist so, dass ein Angreifer dies nutzen könnte, um beliebigen Code (einschließlich Malware) ausführen zu können, der während des Startvorgangs eingeführt wurde, selbst wenn Secure Boot aktiviert ist.
so Dispositivos Netzwerk, Server, Workstations, Desktops und Laptops sowie andere Geräte wie SBCs, bestimmte mobile Geräte, IoT-Geräte usw. wären betroffen.
Darüber hinaus wird es laut Eclypsium sein kompliziert zu mildern und es wird einige Zeit dauern, um eine Lösung zu finden. Es wird eine gründliche Überprüfung der Bootloader erforderlich sein, und die Anbieter sollten neue Versionen der von UEFI CA signierten Bootloader veröffentlichen. Es werden koordinierte Anstrengungen zwischen Entwicklern in der Microsoft Open Source- und Collaborative-Community und anderen betroffenen Systembesitzern erforderlich sein, um BootHole herunterzufahren.
In der Tat haben sie eine gemacht Aufgabenliste Um BootHole in GRUB2 reparieren zu können, benötigen Sie:
- Patch, um GRUB2 zu aktualisieren und die Sicherheitsanfälligkeit zu beseitigen.
- Dass die Entwickler von Linux-Distributionen und andere Anbieter die Updates für ihre Benutzer veröffentlichen. Sowohl auf der Ebene von GRUB2 als auch von Installateuren und Unterlegscheiben.
- Die neuen Shims müssen von der Microsoft UEFI CA für Dritte signiert werden.
- Administratoren von Betriebssystemen müssen natürlich aktualisieren. Es muss jedoch sowohl das installierte System, die Installationsimages als auch die von ihnen erstellten Wiederherstellungs- oder bootfähigen Medien enthalten.
- Die UEFI-Sperrliste (dbx) muss auch in der Firmware jedes betroffenen Systems aktualisiert werden, um die Codeausführung während des Startvorgangs zu verhindern.
Das Schlimmste ist, dass Sie bei der Firmware darauf achten müssen, dass keine Probleme auftreten und die Computer erhalten bleiben im Brick-Modus.
Derzeit sind Unternehmen wie Red Hat, HP, Debian, SUSE, Canonical, Oracle, Microsoft, VMWare, Citrix, das UEFI Security Response Team und OEMs sowie Softwareanbieter Sie arbeiten bereits daran, es zu lösen. Wir müssen jedoch warten, um die ersten Patches zu sehen.
UPDATE
Aber die Effektivität der Entwickler und der Community zu unterschätzen, wäre dumm. Bereits Es gibt mehrere Patch-Kandidaten um es zu mildern, die von Unternehmen wie Red Hat, Canonical usw. kommen. Sie haben dieses Problem als oberste Priorität gekennzeichnet und es zahlt sich aus.
Das Problem? Das Problem ist, dass diese Patches zusätzliche Probleme verursachen. Es erinnert mich an das, was mit den Metldown- und Spectre-Patches passiert ist, dass das Mittel manchmal schlimmer ist als die Krankheit ...