{"id":110421,"date":"2023-10-04T09:10:18","date_gmt":"2023-10-04T07:10:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-ntfs-drajvere-iz-sostava-grub2-pozvolyayushhaya-vypolnit-kod-i-obojti-uefi-secure-boot"},"modified":"2023-10-04T09:10:18","modified_gmt":"2023-10-04T07:10:18","slug":"uyazvimost-v-ntfs-drajvere-iz-sostava-grub2-pozvolyayushhaya-vypolnit-kod-i-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/uyazvimost-v-ntfs-drajvere-iz-sostava-grub2-pozvolyayushhaya-vypolnit-kod-i-obojti-uefi-secure-boot","title":{"rendered":"Sicherheitsanf\u00e4lligkeit im NTFS-Treiber von GRUB2 erm\u00f6glicht das Ausf\u00fchren von Code und Umgehen des UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Im Treiber, der die Arbeit mit dem NTFS-Dateisystem im GRUB2-Bootloader erm\u00f6glicht, wurde eine Sicherheitsanf\u00e4lligkeit (CVE-2023-4692) entdeckt, die es erm\u00f6glicht, eigenen Code auf der Ebene des Bootloaders auszuf\u00fchren, wenn auf ein speziell gestaltetes Abbild des Dateisystems zugegriffen wird. Diese Schwachstelle kann verwendet werden, um den Mechanismus des verifizierten Bootens (UEFI Secure Boot) zu umgehen. <\/p>\n
Die Schwachstelle wird durch einen Fehler im Code des NTFS-Attribut-Parser verursacht «$ATTRIBUTE_LIST» (grub-core\/fs\/ntfs.c), der ausgenutzt werden kann, um benutzerkontrollierte Informationen in einen Speicherbereich au\u00dferhalb des zugewiesenen Puffers zu schreiben. Bei der Verarbeitung eines speziell gestalteten NTFS-Images f\u00fchrt das \u00dcberlaufen zu einer \u00dcberschreibung bestimmter GRUB-Speicherbereiche und unter bestimmten Bedingungen auch zu einem Besch\u00e4digung des UEFI-Firmware-Speicherbereichs, was potenziell die Ausf\u00fchrung eigenen Codes auf Bootloader- oder Firmware-Ebene erm\u00f6glicht. <\/p>\n
Dar\u00fcber hinaus wurde im NTFS-Treiber von GRUB2 eine weitere Schwachstelle (CVE-2023-4693) entdeckt, die es erm\u00f6glicht, den Inhalt eines beliebigen Speicherbereichs beim Parsen des Attributs «$DATA» in einem speziell gestalteten NTFS-Image zu lesen. Unter anderem erm\u00f6glicht die Schwachstelle das Extrahieren vertraulicher Daten, die im Speicher zwischengespeichert sind, oder das Bestimmen von Werten von EFI-Variablen. <\/p>\n
Die Probleme wurden bisher nur durch einen Patch behoben. Den Status der Behebung von Sicherheitsanf\u00e4lligkeiten in den Distributionen k\u00f6nnen Sie auf den folgenden Seiten einsehen: Debian, Ubuntu, SUSE, RHEL, Fedora. Um die Probleme in GRUB2 zu beheben, reicht es nicht aus, nur das Paket zu aktualisieren; es m\u00fcssen auch neue interne digitale Signaturen erstellt und Installer, Bootloader, Kernel-Pakete, fwupd-Firmware und die shim-Schicht aktualisiert werden. <\/p>\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 das Blockieren der Verwendung von digitalen Signaturen f\u00fcr bestimmte Versionen von Komponenten, ohne dass Schl\u00fcssel f\u00fcr den Secure Boot zur\u00fcckgezogen werden m\u00fcssen. Das Schlie\u00dfen von Sicherheitsanf\u00e4lligkeiten \u00fcber SBAT erfordert keine Nutzung der Liste der widerrufenen UEFI-Zertifikate (dbx), sondern erfolgt durch den Austausch des internen Schl\u00fcssels zur Erstellung von Signaturen und zur Aktualisierung von GRUB2, shim und anderen von den Distributionen bereitgestellten Boot-Artefakten. Vor der Einf\u00fchrung von SBAT war die Aktualisierung der Liste der widerrufenen Zertifikate (dbx, UEFI Revocation List) eine zwingende Voraussetzung f\u00fcr das vollst\u00e4ndige Schlie\u00dfen der Sicherheitsanf\u00e4lligkeit, da Angreifer unabh\u00e4ngig vom verwendeten Betriebssystem die UEFI Secure Boot schw\u00e4chen konnten. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"