{"id":99320,"date":"2021-03-03T16:22:39","date_gmt":"2021-03-03T14:22:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot"},"modified":"2021-03-03T16:22:39","modified_gmt":"2021-03-03T14:22:39","slug":"trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"Schwer zu behebende Sicherheitsanf\u00e4lligkeiten in GRUB2, die das Umgehen von UEFI Secure Boot erm\u00f6glichen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Es wurden Informationen \u00fcber 8 Schwachstellen im GRUB2-Bootloader ver\u00f6ffentlicht, die es erm\u00f6glichen, den UEFI Secure Boot-Mechanismus zu umgehen und nicht verifiziertem Code die Ausf\u00fchrung zu erm\u00f6glichen, beispielsweise durch das Einbringen von Malware, die auf der Ebene des Bootloaders oder des Kernels arbeitet. <\/p>\n

Zur Erinnerung: In den meisten Linux-Distributionen wird zur verifiziertem Booten im UEFI Secure Boot-Modus eine kleine shim-Schicht verwendet, die durch eine digitale Signatur von Microsoft beglaubigt ist. Diese Schicht verifiziert GRUB2 mit ihrem eigenen Zertifikat, was es den Entwicklern von Distributionen erm\u00f6glicht, nicht jedes Kernel- und GRUB-Update bei Microsoft zu beglaubigen. Die Schwachstellen im GRUB2 erlauben es, eigenen Code nach der erfolgreichen \u00dcberpr\u00fcfung des shims, jedoch vor dem Laden des Betriebssystems auszuf\u00fchren, indem sie sich in die Vertrauenskette w\u00e4hrend des aktiven Secure Boot-Modus einf\u00fcgen und die volle Kontrolle \u00fcber den weiteren Bootprozess \u00fcbernehmen, einschlie\u00dflich des Ladens eines anderen Betriebssystems, der Modifikation von Betriebssystemkomponenten und dem Umgehen des Lockdown-Schutzes. <\/p>\n

\u00c4hnlich wie bei der BootHole-Sicherheitsanf\u00e4lligkeit des letzten Jahres reicht es nicht aus, den Bootloader zu aktualisieren, um das Problem zu beheben. Ein Angreifer kann unabh\u00e4ngig vom verwendeten Betriebssystem ein bootf\u00e4higes Medium mit einer verwundbaren, \u00e4lteren Version von GRUB2, die durch eine digitale Signatur verifiziert ist, verwenden, um UEFI Secure Boot zu kompromittieren. Das Problem kann nur durch ein Update der Liste der zur\u00fcckgerufenen Zertifikate (dbx, UEFI Revocation List) gel\u00f6st werden, jedoch f\u00fchrt dies dazu, dass die Nutzung \u00e4lterer Installationsmedien mit Linux nicht mehr m\u00f6glich ist. <\/p>\n

Auf Systemen mit Firmware, in denen die Liste der widerrufenen Zertifikate aktualisiert wurde, kann im UEFI Secure Boot-Modus nur mit aktualisierten Linux-Distributionen gebootet werden. Die Distributionen m\u00fcssen ihre Installer, Bootloader, Kernel-Pakete, fwupd-Firmwares und die shim-Schicht aktualisieren und daf\u00fcr neue digitale Signaturen erzeugen. Die Benutzer m\u00fcssen die Installationsabbilder und anderen Boot-Medien aktualisieren sowie die Liste der widerrufenen Zertifikate (dbx) in die UEFI-Firmware laden. Bis die dbx in UEFI aktualisiert ist, bleibt das System unabh\u00e4ngig von den installierten Updates im Betriebssystem anf\u00e4llig. Den Status der Behebung von Sicherheitsanf\u00e4lligkeiten k\u00f6nnen Sie auf den folgenden Seiten bewerten: Ubuntu, SUSE, RHEL, Debian. <\/p>\n

Um Probleme beim Umgang mit zur\u00fcckgezogenen Zertifikaten zu l\u00f6sen, ist geplant, in Zukunft den SBAT-Mechanismus (UEFI Secure Boot Advanced Targeting) zu verwenden, dessen Unterst\u00fctzung f\u00fcr GRUB2, shim und fwupd implementiert wurde. Dieser wird ab den n\u00e4chsten Updates anstelle der Funktionen des dbxtool-Pakets verwendet. SBAT wurde in Zusammenarbeit mit Microsoft entwickelt und sieht vor, dass ausf\u00fchrbare Dateien von UEFI-Komponenten mit zus\u00e4tzlichen Metadaten versehen werden, die Informationen \u00fcber Hersteller, Produkt, Komponente und Version enthalten. Diese Metadaten werden digital signiert und k\u00f6nnen zus\u00e4tzlich in Listen von erlaubten oder verbotenen Komponenten f\u00fcr UEFI Secure Boot aufgenommen werden. Somit erm\u00f6glicht SBAT, bei einem R\u00fcckruf die Versionsnummern von Komponenten zu manipulieren, ohne dass die Schl\u00fcssel f\u00fcr Secure Boot neu generiert oder neue Signaturen f\u00fcr Kernel, shim, grub2 und fwupd erstellt werden m\u00fcssen. <\/p>\n

Identifizierte Schwachstellen: <\/p>\n