Code

UEFI Schwachstelle: LogoFAIL gefährdet viele Rechner

Neu entdeckte Schwachstellen in den Bild-Parsern der UEFI-Implementation fast aller unabhängigen BIOS-Anbieter (IBVs) wie Insyde, AMI oder Phoenix ermöglichen Angriffe auf fast alle Rechner der Plattformen Intel, AMD oder ARM, auf denen Windows oder Linux läuft. Entdeckt wurde die Lücke vom BinarlyResearch Team.

Patches in Arbeit

Patches für die Lücken, die vom Entdecker als LogoFAIL bezeichnet werden, sind in Arbeit, werden aber eine Weile Zeit benötigen, bis sie beim Endanwender ankommen. Eine genaue Liste der betroffenen Geräte steht bisher nicht zur Verfügung. Rechner von Apple sind nicht betroffen, da sie beim Booten keine Add-On-Images zulassen. Rechner von Dell sind ebenfalls außen vor.

Bild-Parser ausgenutzt

Der LogoFAIL-Exploit umgeht Sicherheitsmaßnahmen bei Hard- und Software, indem er früh im Bootprozess das Startlogo im UEFI-Code austauscht, das erscheint, wenn das System nach erfolgreichem POST hochfährt. Der Angriff findet während der auf den POST folgenden Phase Driver Execution Environment (DXE) statt. Der Exploit ist nur schwer zu entdecken und genauso schwer zu entfernen. Da er auf den Speichermedien keinen Code hinterlässt, übersteht er auch die Neuinstallation des Betriebssystems.

Der Angreifer benötigt Zugang über ein Root-Terminal, um die vorhandene Bilddatei zu überschreiben. Wenn das gelingt, können anschließend Bootkits mit schädlichen Payloads platziert werden. Vertiefte Informationen über diese Lücken in UEFI-Firmware-Implementierungen finden sich in der Analyse von Binarly. Ein YouTube Video demonstriert den Exploit.

Teilt den Beitrag, falls ihr mögt

22 Kommentare

    1. Die Kette der Verantwortung geht vom BIOS-Herausgeber über den Mainboard-Hersteller zu den Herstellern der eigentlichen Hardware, die dann ihre Kunden informieren sollten. Wenn dein BIOS/UEFI von Phoenix, AMI oder Insyde ist, bist du verwundbar. Wie bei vielen anderen Verwundbarkeiten auch sind vermutlich weniger Heimanwender als Enterprise-Rechner im Blickfeld potenzieller Angreifer. Aber eine latente Gefahr besteht natürlich. Wie sich das nun ausspielt und was man tun kann, bleibt abzuwarten. Da liegen noch keine verwendbaren Informationen vor.

      1
      1. Danke für deine Einordnung und Einschätzung. Da ich mehrere Rechner verwaltet (ThinkPad Notebooks, Asus Mainboards und Asrock), wird sich da ein potentieller Kandidat schon finden.
        Also warten wir ab.
        Ich erinnere mal an den Spectre Bug zurück, der verhältnismäßig leicht geschlossen werden konnte. Das sete ich hier nicht.

        0
  1. Wenn das über ein Firmwareupdate vom Hersteller geht, dann sähe das ein oder andere Laptop auch kein Update mehr. Entsorgen? Ganz sicher nicht! Ich bin gespannt was passieren wird. Haben wir jetzt eine Sicherheits Update Situation wie bei Smartphones?

    0
  2. Ich habe ein Asus Mainboard mit AMI Bios, das im Jahr 2018 das letzte Firmwareupdate bekommen hat. Da kann ich ja sicher davon ausgehen, dass das dort nicht mehr gepatcht wird?
    Und bei vielen anderen, älteren Systemen bestimmt auch nicht mehr. Kann ich dann alle Jubeljahre das Mainboard tauschen, weil das UEFI kein Update mehr bekommt und sich nach und nach immer mehr Sicherheitslücken auftun? Oder muss man da in Sachen Sicherheit sehr paranoid sein?
    Das wäre ja in Sachen Nachhaltigkeit ansonsten auch keine tolle Lösung.

    1
        1. Nitrokey, Tuxedo sollte auch was haben und dann gibt es noch Purism. Dazu kommen noch ein, zwei weitere aber da fällt mir der Name gerade nicht ein. Englischer Hersteller oder die Spanier …ich weiß es nicht mehr aber das lässt sich heraus finden.

          0
      1. Wenn ich das habe, habe ich doch aber eh ganz andere Möglichkeiten… Den einzigen “Vorteil” den ich als Angreifer dann habe, ist, dass man meine Malware nicht so einfach wieder los wird. Klingt für mich ein wenig wie ein neues Addon für das Schweizer Taschenmesser der Geheimdienste. Was es nicht weniger kritisch macht, keine Frage.

        0
          1. Kann so etwas auch per Firmware(z.B. NVMEs) passieren?

            Ich hatte eine Konstellation in der es bei Debian 12 mit einer NVME dazu kam, dass SecureBoot deaktiviert wurde, aber der Debian dennoch gestartet ist ohne, dass der Start verhindert wurde. Das ist nur mit einer NVME passiert, mit dem Bios-Lockdown-Modus des Mainboards war Secure Boot wieder mit der NVME aktiv. Mit einer HDD passierte das Verhalten nicht. Das ganze ist auf einem Intel-NUC12 mit HSI-3 aufgetreten.

            Das komische, sobald diese NVME im System eingebaut war, trat das Verhalten auch mit dem Debian USB-Live-Stick auf.

            Hast du vielleicht eine Erklärung dafür, ein Fehler in Debian?

            1
      1. Genau und eigentlich sollte jeder, der viel im Netz ist, entweder einen extra PC dafuer haben, oder eine reine porteus instanz, oder von livecd, ohne Verbindung zum Restnetzwerk oder eben eine richtige FW.
        Ich habe 2 kasscadierende FW, weil ich die eine Buechse eben noch uebrig hatte.
        Einmal fuer den Inetpc und die 2. nochmal vor dem Serversetz.

        Oder wie ich auch wer kein UEFI Bios auf den Rechnern hat, der brauch auch kein patch. 🙂

        0
          1. Ich, habe in der Wohnung einen extra Internetrechner und im Urlaub, da habe ich ein altes NB mit usb stick da ist ventoy drauf mir 2-3 iso files. Und je nachdem wie mir ist starte ich dann von dort.

            Meinen Kunden habe ich schon lange abgewoehnt mich ausserhalb der Geschaeftszeiten anzurufen. 😉

            0

Kommentar hinterlassen