🚀 go-pugleaf

Hallo

Ich stieß eben bei Golem auf diesen Artikel (https://glm.io/186321) der
auf den Artikel der "Finder" dieser Lücke im UEFI verweist (technisch,
eher für Experten)


https://eclypsium.com/blog/ueficanhazbufferoverflow-widespread-impact-from-vulnerability-in-popular-pc-and-server-firmware/

So wie ich beides verstehe gibt es eine "ungeschützte" Variable
(TCG2_CONFIGURATION) wobei nicht klar wird warum die nicht "geschützt"
ist oder wie das gehen sollte.

Und wenn man diese erreichen kann und länger macht gibt es einen
Pufferüberlauf. Im UEFI-Bios. Und dort im "Securecore" genau an der
Stelle wo es um den TPM-Chip geht.

Das ist eigentlich eine Stelle an der niemand auch nur einen Fehler
dulden sollte oder? UEFI sollte sicheres Booten ermöglichen. Mit TPM
auch kryptografisch abgesichert um verifizieren zu können das nur
Signierte Bootloader von einem nicht-manipulierten BIOS/UEFI gestartet
würden.

Alles Makulatur, Mumpitz, Augenwischerei? Wenn das zutrifft kann
offenbar jeder ein Betroffenes Board (und das scheinen einige
CPU-System-architekturen zu sein) einfach so übernehmen, eine permanente
Backdoor einpflanzen und das war's mit dem Versprechen von Sicherheit
und Überprüfbarkeit.

Unklar ist mir hier nun wie man zur Bootzeit an diese Variable heran
kommt und sie setzen könnte. Ich nehme an die ist evtl. in einer Datei
in der EFI-Partition gespeichert und man könnte sie dort bearbeiten.
Dann müsste offenbar noch eine Funktion des UEFI aufgerufen werden, dem
namen nach etwas das die Systemkonfiguration abfragt. Und "Puff" ist der
Speicherüberlauf da und man könnte eigenen Code implantieren. Wirklich?

Das gilt doch nur für einen lauf, bestenfalls ab Booten. Werden diese
Variablen evtl. danach im RAM behalten und im SMM der CPU ausgewertet?
Und angehängter Code im Übergelaufenen Speicher dann auch noch
AUSGEFÜHRT? WTF???

Damit ist es aber doch immer noch nicht persistent, es sei denn in der
EFI-Partition läge ein zusätzliches Programm das diesen Angriff jedesmal
ausführte. Oder könnte Teil des Angriffs sein das zugleich auch die
UEFI-Firmware quasi neu geflasht wird womit Maligner Code direkt
eingebettet wäre?

Unter Mitigations lese ich nur Allgemeinplätze heraus, man solle
feststellen ob man betroffen ist und Hersteller nach Firmware-update fragen.

Ich denke aber das man doch auch an anderen Stellen fündig werden müßte
- nach einem Angriff und Erfolgter Infektion oder? Entweder in der
EFI-Partition oder... Prüfsumme, Hash o.a. der Firmware??? Letzteres
kann man wohl einfach neu berechnen und mit speichern. Das Modifizierte
Bios überprüfte dann nur seine eigene Modifiziertheit.

Weiß das jemand genauer, was spielt da wie zusammen damit das Persistent
wird? Und gibt es nur die Option neue Firmware ein zu spielen.

Die Liste der "-lake" ist lang. Ich gehe nicht davon aus das ich ein
Betroffenes System hätte weil mein Zeug hier insgesamt eher Älter als
Alt ist.

Aber ich finde es einen Imponierenden Beleg dafür das man mit UEFI ein
überkomplexes Monstrum schuf mit dem man Sicherheit verspricht - aber;
wieder mal; nicht liefern kann. Und den Brüller finde ich das
ausgerechnet der "Sicherheits-Chip" TPM davon betroffen ist. Den wollten
viele auch nicht haben, ich ebenso wenig. "Trusted Computing. Sounds
Cool. Isn't it?"

Erinnert mich unwillkürlich an Linux systemd der vom reinen Ersatz eines
SysV-Init mutiert zu einem Monstrum das immer mehr Dienste/Funktionen zu
vereinnahmen scheint. Und dabei auch ab und an über die eigenen
Fuß(noten) stolpert. :-)

Und da stellt sich mir die Frage ob das wirklich nötig war. Zwecke gibt
es sicherlich. Aber als Anwender möchte ich die Wahl behalten und dabei
nicht behindert werden. Wenn ich BIOS/CSM will->Check! Wenn ich SysVInit
will->Check! Und genau diese Wahl fehlt heute. Man wird quasi unsanft
geprügelt das neuere/bessere nehmen zu müssen und dann kommt immer
wieder "Hoppla, es ist nicht besser" dabei raus.

Bye/
   /Kay

--
Geschrieben auf einem Samsung Laptop mit Devuan :)
CPU: Intel® Core™ i5-3210M (=Ivy-bridge)