{"id":90288,"date":"2020-07-30T13:42:19","date_gmt":"2020-07-30T11:42:19","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/kriticheskaya-uyazvimost-v-zagruzchike-grub2-pozvolyayushhaya-obojti-uefi-secure-boot"},"modified":"2020-07-30T13:42:19","modified_gmt":"2020-07-30T11:42:19","slug":"kriticheskaya-uyazvimost-v-zagruzchike-grub2-pozvolyayushhaya-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/kriticheskaya-uyazvimost-v-zagruzchike-grub2-pozvolyayushhaya-obojti-uefi-secure-boot","title":{"rendered":"Kritische Schwachstelle im Bootloader GRUB2, die es erm\u00f6glicht, UEFI Secure Boot zu umgehen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Im GRUB2-Bootloader entdeckt<\/a><\/noindex> 8 Schwachstellen. Die gef\u00e4hrlichste Problem<\/a><\/noindex> (CVE-2020-10713<\/a><\/noindex>), die den Codenamen BootHole tr\u00e4gt, erm\u00f6glicht es<\/a><\/noindex> den UEFI Secure Boot-Mechanismus zu umgehen und nicht verifiziertes Malware zu installieren. Ein Merkmal dieser Schwachstelle ist, dass es nicht ausreicht, GRUB2 zu aktualisieren, da ein Angreifer ein bootf\u00e4higes Medium mit einer alten, anf\u00e4lligen Version, die mit einer digitalen Signatur signiert ist, verwenden kann. Der Angreifer kann den Verifizierungsprozess nicht nur von Linux, sondern auch von anderen Betriebssystemen, einschlie\u00dflich Windows<\/a><\/noindex>. <\/p>\n

Das Problem wird nur durch ein Update im System der Liste der widerrufenen Zertifikate<\/a><\/noindex> (dbx, UEFI Revocation List) behoben, aber in diesem Fall geht die M\u00f6glichkeit verloren, alte Installationsmedien mit Linux zu verwenden. Einige Hardwarehersteller haben bereits die aktualisierte Liste der widerrufenen Zertifikate in ihre Firmware integriert, auf solchen Systemen kann im UEFI Secure Boot-Modus nur mit aktualisierten Versionen der Linux-Distributionen gebootet werden. <\/p>\n

Um die Schwachstelle in den Distributionen zu beheben, m\u00fcssen auch die Installer, Bootloader, Kernel-Pakete, fwupd-Firmware und die shim-Schicht aktualisiert werden, wobei neue digitale Signaturen f\u00fcr sie generiert werden m\u00fcssen. Benutzer m\u00fcssen die Installationsabbilder und andere bootf\u00e4hige Medien aktualisieren sowie die Liste der widerrufenen Zertifikate (dbx) in die UEFI-Firmware laden. Bis die dbx in der UEFI aktualisiert wird, bleibt das System verwundbar, unabh\u00e4ngig von den installierten Updates im Betriebssystem. <\/p>\n

Schwachstelle wird verursacht<\/a><\/noindex> Buffer\u00fcberlauf, der ausgenutzt werden kann, um beliebigen Code w\u00e4hrend des Bootvorgangs auszuf\u00fchren.
\nDie Schwachstelle tritt beim Parsen des Inhalts der grub.cfg-Konfigurationsdatei auf, die sich normalerweise im ESP (EFI System Partition) befindet und von einem Angreifer, der Administratorrechte hat, bearbeitet werden kann, ohne die Integrit\u00e4t der signierten Executables von shim und GRUB2 zu verletzen. Aufgrund von Fehler<\/a><\/noindex> einem Fehler im Konfigurationsparser gab der Fehlerbehandlungsmechanismus YY_FATAL_ERROR lediglich eine Warnung aus, ohne das Programm zu beenden. Das Risiko dieser Schwachstelle wird durch die Notwendigkeit privilegierten Zugriffs auf das System gemildert, trotzdem k\u00f6nnte das Problem f\u00fcr die Implementierung verborgener Rootkits relevant werden, wenn physischer Zugang zu der Hardware besteht (bei der M\u00f6glichkeit, von einem eigenen Medium zu booten).<\/p>\n

In den meisten Linux-Distributionen wird f\u00fcr den verifizierten Start eine kleine Shim-Schicht<\/a><\/noindex>, die durch eine digitale Signatur von Microsoft zertifiziert ist. Diese Schicht verifiziert GRUB2 mit ihrem eigenen Zertifikat, was es den Entwicklern der Distributionen erm\u00f6glicht, nicht jedes Update des Kernels und GRUB bei Microsoft zertifizieren zu m\u00fcssen. Die Schwachstelle erm\u00f6glicht es, durch die \u00c4nderung des Inhalts von grub.cfg eigenen Code nach erfolgreicher Verifizierung von Shim auszuf\u00fchren, jedoch vor dem Laden des Betriebssystems, sich in die Vertrauenskette im aktiven Secure Boot-Modus einzuschleusen und vollst\u00e4ndige Kontrolle \u00fcber den weiteren Boot-Prozess zu erhalten, einschlie\u00dflich des Ladens eines anderen OS, der Modifizierung von Betriebssystemkomponenten und dem Umgehen von Schutzma\u00dfnahmen. Sperrmodus<\/a><\/noindex>. <\/p>\n

\"Kritische<\/a><\/noindex><\/center><\/p>\n

Andere Schwachstellen in GRUB2:<\/p>\n