{"id":149133,"date":"2025-11-21T17:11:55","date_gmt":"2025-11-21T15:11:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/6-uyazvimostej-v-zagruzchike-grub2-pozvolyayushhih-obojti-uefi-secure-boot"},"modified":"2025-11-21T17:11:55","modified_gmt":"2025-11-21T15:11:55","slug":"6-uyazvimostej-v-zagruzchike-grub2-pozvolyayushhih-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/6-uyazvimostej-v-zagruzchike-grub2-pozvolyayushhih-obojti-uefi-secure-boot","title":{"rendered":"6 Schwachstellen im GRUB2-Bootloader erm\u00f6glichen Umgehung des UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Ein Patchset wurde ver\u00f6ffentlicht, das 6 Sicherheitsanf\u00e4lligkeiten im GRUB2-Bootloader behebt, von denen die meisten zu einer Verwendung des Speichers nach seiner Freigabe (use-after-free) f\u00fchren. Die potenziell identifizierten Probleme k\u00f6nnten genutzt werden, um den UEFI Secure Boot-Verifizierungsmechanismus zu umgehen. Der Status der Behebung der Schwachstellen in den Distributionen kann auf den folgenden Seiten bewertet werden: Debian, Ubuntu, SUSE, RHEL, Arch und Fedora. Um die Probleme in GRUB2 zu beheben, reicht es nicht aus, nur das Paket zu aktualisieren; es ist auch erforderlich, neue interne digitale Signaturen zu erstellen und die Installer, Bootloader, Kernel-Pakete, fwupd-Firmware und die shim-Schicht zu aktualisieren. <\/p>\n
Identifizierte Schwachstellen: <\/p>\n
\n
CVE-2025-61661 \u2014 Buffer\u00fcberlauf in der Funktion grub_usb_get_string(), der bei der Verarbeitung von UTF-8- und UTF-16-codierten Zeichenfolgen, die beim Anschluss von USB-Ger\u00e4ten \u00fcbertragen werden, ausgenutzt werden kann. Das Problem entsteht, weil der Puffer basierend auf der im ersten USB-Ger\u00e4temeldung angegebenen Zeichenfolgenl\u00e4nge zugewiesen wurde, w\u00e4hrend die Gr\u00f6\u00dfe w\u00e4hrend der Umwandlung der Codierung auf Basis der nachfolgenden Leseoperationen vom USB-Ger\u00e4t berechnet wurde. Daher kann ein modifiziertes USB-Ger\u00e4t, das urspr\u00fcnglich einen zu niedrigen Gr\u00f6\u00dfenwert zur\u00fcckgibt, f\u00fcr den Angriff verwendet werden.\n
CVE-2025-61663, CVE-2025-61664, CVE-2025-54770, CVE-2025-61662 \u2014 fehlende Bereinigung der Befehls-Handler «normal», «normal_exit», «net_set_vlan» und «gettext» beim Entladen der Module «normal», «net» und «gettext», was Bedingungen f\u00fcr den Zugriff auf Speicher nach dessen Freigabe (use-after-free) schafft, wenn die gekennzeichneten Befehle nach dem Entladen der entsprechenden Module ausgef\u00fchrt werden. \u00c4hnliche Schw vulnerabilities wurden auch f\u00fcr die Befehle «functional_test» und «all_functional_test» gefunden, aber ihnen wurden keine CVE-Identifikatoren zugewiesen, da diese Befehle Teil der Testbibliothek sind und nicht in Produktionsversionen enthalten sein sollten.\n
CVE-2025-54771 \u2014 Fehler bei der Z\u00e4hlung der Verweise auf Strukturen «fs» in der Funktion grub_file_close(), der zu einem Zugriff auf Speicher nach dessen Freigabe (use-after-free) f\u00fchrt. <\/ul>\n
In den meisten Linux-Distributionen wird f\u00fcr die verifizierte Boot-Funktion im UEFI Secure Boot-Modus eine kleine Schicht namens shim verwendet, die durch ein digitales Zertifikat 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 k\u00f6nnen es erm\u00f6glichen, eigenen Code nach der erfolgreichen Verifizierung von shim, jedoch vor dem Laden des Betriebssystems auszuf\u00fchren. Dabei wird die Vertrauens-Chain im aktiven Secure Boot-Modus unterbrochen, was vollst\u00e4ndige Kontrolle \u00fcber den weiteren Boot-Prozess erm\u00f6glicht, beispielsweise zum Laden eines anderen Betriebssystems, zur Modifikation von Betriebssystemkomponenten und zum Umgehen des Lockdown-Schutzes. <\/p>\n
Um eine Schwachstelle ohne Widerruf der digitalen Signatur zu schlie\u00dfen, k\u00f6nnen Distributionen den SBAT-Mechanismus (UEFI Secure Boot Advanced Targeting) verwenden, dessen Unterst\u00fctzung in den meisten beliebten Linux-Distributionen f\u00fcr GRUB2, shim und fwupd implementiert ist. SBAT wurde in Zusammenarbeit mit Microsoft entwickelt und bedeutet, dass zus\u00e4tzlich zu den ausf\u00fchrbaren Dateien von UEFI-Komponenten Metadaten hinzugef\u00fcgt werden, die Informationen \u00fcber Hersteller, Produkt, Komponente und Version enthalten. Diese Metadaten werden digital signiert und k\u00f6nnen separat in die Listen der genehmigten oder verbotenen Komponenten f\u00fcr UEFI Secure Boot aufgenommen werden. <\/p>\n
SBAT erm\u00f6glicht es, die Verwendung von digitalen Signaturen f\u00fcr bestimmte Versionen von Komponenten zu blockieren, ohne dass die Schl\u00fcssel f\u00fcr Secure Boot zur\u00fcckgezogen werden m\u00fcssen. Das Blockieren von Schwachstellen \u00fcber SBAT erfordert nicht die Verwendung der UEFI-R\u00fcckrufliste (dbx), sondern erfolgt auf der Ebene des Austauschs des internen Schl\u00fcssels zur Erstellung von Signaturen und zur Aktualisierung von GRUB2, shim und anderen mitgelieferten Boot-Artefakten. Vor der Einf\u00fchrung von SBAT war die Aktualisierung der R\u00fcckrufliste (dbx, UEFI Revocation List) eine zwingende Voraussetzung f\u00fcr das vollst\u00e4ndige Blockieren einer Schwachstelle, da ein Angreifer, unabh\u00e4ngig vom verwendeten Betriebssystem, ein Bootmedium mit einer alten, anf\u00e4lligen Version von GRUB2, das durch eine digitale Signatur best\u00e4tigt wurde, zur Kompromittierung des UEFI Secure Boot nutzen konnte. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"