{"id":104320,"date":"2022-06-08T15:36:43","date_gmt":"2022-06-08T13:36:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot"},"modified":"2022-06-08T15:36:43","modified_gmt":"2022-06-08T13:36:43","slug":"uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"Schwachstellen in GRUB2, die das Umgehen von UEFI Secure Boot erm\u00f6glichen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Im Bootloader GRUB2 wurden 7 Sicherheitsanf\u00e4lligkeiten behoben, die eine Umgehung des UEFI Secure Boot-Mechanismus erm\u00f6glichen und das Ausf\u00fchren von nicht verifiziertem Code erm\u00f6glichen, wie zum Beispiel die Einschleusung von Malware, die auf der Ebene des Bootloaders oder des Kernels arbeitet. Zus\u00e4tzlich wird eine Sicherheitsanf\u00e4lligkeit im shim-Layer erw\u00e4hnt, die ebenfalls eine Umgehung von UEFI Secure Boot erm\u00f6glicht. Die Gruppe von Sicherheitsanf\u00e4lligkeiten erhielt den Codenamen Boothole 3, analog zu \u00e4hnlichen Problemen, die zuvor im Bootloader identifiziert wurden. <\/p>\n
Um die Probleme in GRUB2 und shim zu beheben, k\u00f6nnen die Distributionen den SBAT-Mechanismus (UEFI Secure Boot Advanced Targeting) verwenden, dessen Unterst\u00fctzung f\u00fcr GRUB2, shim und fwupd implementiert wurde. SBAT wurde gemeinsam mit Microsoft entwickelt und sieht vor, dass zus\u00e4tzliche Metadaten zu den ausf\u00fchrbaren Dateien der UEFI-Komponenten hinzugef\u00fcgt werden, die Informationen \u00fcber Hersteller, Produkt, Komponente und Version enthalten. Die angegebenen Metadaten werden mit einer digitalen Signatur signiert und k\u00f6nnen separat in Listen zugelassener oder verbotener UEFI Secure Boot-Komponenten aufgenommen werden. <\/p>\n
In den meisten Linux-Distributionen wird f\u00fcr die verifizierte Bootf\u00e4higkeit im UEFI Secure Boot-Modus eine kleine shim-Schicht verwendet, die durch eine digitale Signatur von Microsoft signiert ist. Diese Schicht verifiziert GRUB2 mit ihrem eigenen Zertifikat, was es den Entwicklern der Distributionen erm\u00f6glicht, nicht jedes Kernel- und GRUB-Update bei Microsoft zu signieren. Schwachstellen in GRUB2 erm\u00f6glichen die Ausf\u00fchrung eigenen Codes nach erfolgreicher Verifizierung von shim, jedoch vor dem Laden des Betriebssystems, sodass sie sich in die Vertrauenskette w\u00e4hrend des aktiven Secure Boot-Modus einschleichen und die vollst\u00e4ndige Kontrolle \u00fcber den weiteren Bootvorgang erlangen k\u00f6nnen, einschlie\u00dflich des Ladens eines anderen Betriebssystems, der Modifikation von Betriebssystemkomponenten und der Umgehung des Lockdown-Schutzes. <\/p>\n
Um die Probleme im Bootloader zu beheben, m\u00fcssen die Distributionen neue interne digitale Signaturen erstellen und Installer, Bootloader, Kernel-Pakete, fwupd-Firmware und den shim-Layer aktualisieren. Vor der Einf\u00fchrung von SBAT war die Aktualisierung der Liste der widerrufenen Zertifikate (dbx, UEFI Revocation List) eine Voraussetzung f\u00fcr die vollst\u00e4ndige Blockierung der Sicherheitsanf\u00e4lligkeit, da ein Angreifer, unabh\u00e4ngig vom verwendeten Betriebssystem, ein Bootmedium mit einer alten, anf\u00e4lligen Version von GRUB2, die mit einer digitalen Signatur signiert war, zur Kompromittierung von UEFI Secure Boot verwenden konnte. <\/p>\n
Anstelle des Widerrufs der Signatur erm\u00f6glicht SBAT, deren Verwendung f\u00fcr einzelne Versionsnummern der Komponenten zu blockieren, ohne die Schl\u00fcssel f\u00fcr Secure Boot widerrufen zu m\u00fcssen. Die Blockierung von Sicherheitsanf\u00e4lligkeiten \u00fcber SBAT erfordert nicht die Verwendung der Liste der widerrufenen UEFI-Zertifikate (dbx), sondern erfolgt auf der Ebene des Austauschs des internen Schl\u00fcssels zur Erstellung von Signaturen und der Aktualisierung von GRUB2, shim und anderen Boot-Artefakten, die von den Distributionen bereitgestellt werden. Derzeit wurde die Unterst\u00fctzung f\u00fcr SBAT bereits in den meisten beliebten Linux-Distributionen hinzugef\u00fcgt. <\/p>\n
Festgestellte Schwachstellen: <\/p>\n
\n
CVE-2021-3696, CVE-2021-3695 - Buffer\u00fcberlauf im Heap bei der Verarbeitung von speziell gestalteten PNG-Bildern, die theoretisch f\u00fcr die Ausf\u00fchrung von Angreifercode und das Umgehen des UEFI Secure Boot verwendet werden k\u00f6nnen. Es wird darauf hingewiesen, dass das Problem schwer ausnutzen l\u00e4sst, da f\u00fcr die Erstellung eines funktionsf\u00e4higen Exploits viele Faktoren und Informationen \u00fcber die Speicheranordnung erforderlich sind.\n
CVE-2021-3697 - Bufferunterlauf im JPEG-Bildverarbeitungscode. Die Ausnutzung des Problems erfordert Informationen \u00fcber die Speicheranordnung und befindet sich in etwa auf dem gleichen Schwierigkeitsgrad wie das Problem mit PNG (CVSS 7.5).\n
CVE-2022-28733 \u2014 Ganzzahlen\u00fcberlauf in der Funktion grub_net_recv_ip4_packets(), der es erm\u00f6glicht, den Parameter rsm->total_len durch das Senden eines speziell gestalteten IP-Pakets zu beeinflussen. Dieses Problem wird als das gef\u00e4hrlichste der aufgef\u00fchrten Schwachstellen angesehen (CVSS 8.1). Bei erfolgreicher Ausnutzung erlaubt die Schwachstelle, Daten au\u00dferhalb des Puffers zu schreiben, indem absichtlich zu wenig Speicher zugewiesen wird.\n
CVE-2022-28734 \u2014 Ein Byte-Puffer\u00fcberlauf bei der Verarbeitung getrennter HTTP-Header. Dieses Problem kann zu einer Besch\u00e4digung der GRUB2-Metadaten f\u00fchren (Schreiben eines Null-Bytes direkt am Ende des Puffers) bei der Analyse speziell gestalteter HTTP-Anfragen.\n
CVE-2022-28735 \u2014 Problem im shim_lock-Verifikator, das das Laden von Dateien erm\u00f6glicht, die nicht zum Kernel geh\u00f6ren. Die Schwachstelle kann ausgenutzt werden, um im UEFI Secure Boot-Modus unzertifizierte Kernel-Module oder nicht \u00fcberpr\u00fcften Code zu laden.\n
CVE-2022-28736 \u2014 Zugriff auf bereits freigegebenen Speicherbereich in der Funktion grub_cmd_chainloader() durch das mehrfache Ausf\u00fchren des Befehls chainloader, der zum Laden von Betriebssystemen verwendet wird, die in GRUB2 nicht unterst\u00fctzt werden. Die Ausnutzung kann zur Ausf\u00fchrung von Angreifer-Code f\u00fchren, wenn der Angreifer in der Lage ist, die Speicherverteilung in GRUB2 zu bestimmen.\n
CVE-2022-28737 \u2014 Puffer\u00fcberlauf in der shim-Schicht, der in der Funktion handle_image() beim Laden und Ausf\u00fchren speziell gestalteter EFI-Images auftritt. <\/ul>\n