{"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\/novosti-interneta\/kriticheskaya-uyazvimost-v-zagruzchike-grub2-pozvolyayushhaya-obojti-uefi-secure-boot","title":{"rendered":"Kritische Schwachstelle im GRUB2-Bootloader, die UEFI Secure Boot umgehen kann","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Im GRUB2-Bootloader 35 Schwachstellen identifiziert, auf deren Grundlage mehrere Angriffsszenarien entwickelt wurden, die es erm\u00f6glichen, AES-Schl\u00fcssel aus der Enklave zu extrahieren oder die Ausf\u00fchrung eigenen Codes durch das Schaffen von Bedingungen f\u00fcr die Besch\u00e4digung des Speicherinhalts zu organisieren.<\/a><\/noindex> 8 Schwachstellen. Die gef\u00e4hrlichste ein 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 besonderes Merkmal dieser Schwachstelle ist, dass ein einfaches Update von GRUB2 nicht ausreicht, da ein Angreifer ein bootf\u00e4higes Medium mit einer alten, verwundbaren Version verwenden kann, die durch eine digitale Signatur verifiziert wurde. Der Angreifer kann den Verifizierungsprozess nicht nur von Linux, sondern auch von anderen Betriebssystemen kompromittieren, einschlie\u00dflich Windows<\/a><\/noindex>. <\/p>\n

Das Problem kann nur durch ein Update des Widerrufslisten<\/a><\/noindex> (dbx, UEFI Widerrufsliste) gel\u00f6st werden, aber in diesem Fall wird die M\u00f6glichkeit zur Verwendung \u00e4lterer Installationsmedien mit Linux verloren gehen. Einige Hardwarehersteller haben bereits aktualisierte Widerrufslisten in ihre Firmware integriert; auf solchen Systemen wird im UEFI Secure Boot-Modus nur der Zugang zu aktualisierten Versionen von Linux-Distributionen m\u00f6glich sein. <\/p>\n

Um die Sicherheitsanf\u00e4lligkeit 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 erstellt werden. Nutzer m\u00fcssen die Installationsabbilder und andere bootf\u00e4hige Medien aktualisieren und die Liste der widerrufenen Zertifikate (dbx) in die UEFI-Firmware laden. Bis dbx in der UEFI aktualisiert wird, bleibt das System anf\u00e4llig, unabh\u00e4ngig von installierten Updates im Betriebssystem. <\/p>\n

Sicherheitsanf\u00e4lligkeit durch<\/a><\/noindex> einem Puffer\u00fcberlauf, der ausgenutzt werden kann, um beliebigen Code im Bootprozess auszuf\u00fchren.
\nDie Anf\u00e4lligkeit tritt beim Parsen des Inhalts der Konfigurationsdatei grub.cfg auf, die normalerweise im ESP (EFI System Partition) abgelegt ist und von einem Angreifer mit Administratorrechten bearbeitet werden kann, ohne die Integrit\u00e4t der signierten ausf\u00fchrbaren Dateien von shim und GRUB2 zu beeintr\u00e4chtigen. Aufgrund von Fehlers<\/a><\/noindex> Im Code des Konfigurationsparsers gab der Handler f\u00fcr fatale Parsierungsfehler YY_FATAL_ERROR lediglich eine Warnung aus und beendete das Programm nicht. Das Risiko der Verwundbarkeit wird durch die Notwendigkeit eines privilegierten Zugangs zum System gemindert. Dennoch k\u00f6nnte das Problem f\u00fcr die Implementierung versteckter Rootkits relevant werden, falls physischer Zugang zur Hardware besteht (insbesondere wenn das Booten von einem eigenen Tr\u00e4ger m\u00f6glich ist).<\/p>\n

In den meisten Linux-Distributionen wird zur verifizierten Boot-Prozess eine kleine shim-Schicht<\/a><\/noindex>, die digital von Microsoft signiert ist, verwendet. Diese Schicht verifiziert GRUB2 mit ihrem eigenen Zertifikat, was es den Entwicklern der Distributionen erm\u00f6glicht, nicht jedes Kernel- oder GRUB-Update bei Microsoft zu signieren. Die Verwundbarkeit erlaubt es, durch \u00c4nderung des Inhalts von grub.cfg eigenen Code nach erfolgreicher Verifizierung des Shim auszuf\u00fchren, jedoch vor dem Booten des Betriebssystems. Dadurch wird in die Vertrauenskette eingegriffen, w\u00e4hrend der Secure Boot aktiv ist, und vollst\u00e4ndige Kontrolle \u00fcber den weiteren Bootprozess erlangt, einschlie\u00dflich des Bootens eines anderen Betriebssystems, der Modifikation von Betriebssystemkomponenten und der Umgehung von Schutzma\u00dfnahmen. Lockdown.<\/a><\/noindex>. <\/p>\n

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

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