Vorab die gute Nachricht: Es gibt keinen Grund sich im Rübenkeller zu verschanzen und das Ende der Zivilisation bei 2 Dosen Bohnen mit Speck auszusitzen. Alles ist gut. Aber fangen wir am Anfang an.

CVE-2023-43641

Die genauen technischen Details, aufbereitet von Menschen, die sich damit besser auskennen als ich, gibt es hier.

Die Schwachstelle existiert in libcue, einer Bibliothek zum Parsen von cuesheets. Was sind cuesheets? Das sind Dateien (.cue), die das Track-Layout auf einer (Audio-)CD beschreiben. Was ist eine CD? Nun, sowas Ähnliches wie eine Schallplatte aber mit mehr Hexenwerk. Was ist eine Schall...ach, lassen wir das.

GNOME indiziert Dateien für die Suche, unter anderem eben auch eventuell vorhandene cuesheets. Das geschieht automatisch wenn man Dateien in bestimmten Sub-Directories (in diesem Fall ~/Downloads) hinzufügt oder ändert. Wieso der rotbemützte Unruhestifter dazu die komplette Datei parsen muss, kann ich nicht sagen, ich bin mit der Mechanik dahinter nicht vertraut aber in der dazu verwendeten libcue Bibliothek existiert kein Check, ob beim Parsen der Track-Offsets in der Datei ein Integer-Überlauf stattfindet und der Index deswegen negativ ist. Dieser negative Index erlaubt, außerhalb des Adressbereichs des Arrays zu schreiben und wenn man dem Programm auf diese Weise Shellcode unterjubelt, können wundersame Dinge passieren - vom langweiligen Segmentation Fault bis zur RCE.

Nun wurde ja in den Medien so einiges geschrieben, von einer "ernsthaften Bedrohung" war die Rede und der eingangs erwähnte Rübenkeller sah nicht gänzlich unattraktiv aus. Wie gefährlich ist der aufmüpfige Gartenzwerg aber tatsächlich?

Das Bedrohungsszenario

Ja, die Schwachstelle ist nicht schön, vor allem da das Betriebssystem die Indizierung übernimmt und eventuell vorhandene AV-Lösungen das möglicherweise selig ignorieren. Steht uns eine Riesenwelle von Kompromittierungen bevor? Nein, ich glaube nicht und zwar aus folgenden Gründen:

• Die Anzahl der Linux-Systeme, die libcue in einer verwundbaren Konstellation einsetzen ist vergleichsweise gering. Den größten Anteil daran haben wohl Client-Systeme. Die Server die ich bis jetzt gesehen habe sind zum allergrößten Teil headless, der Anteil mit GUI (also möglicher GNOME-Installation) vernachlässigbar.
• Client-Systeme bekommen eher mal ein Update als ein Server, der monatelang traurig in einer Ecke vor sich hinvegetiert. Viele Clients haben automatische Updates aktiviert.
• Der Großteil der Firmen die aus mehr als 2 Leuten bestehen, verwenden eine Windows-Umgebung für ihre Clients.
• Es gibt bereits Patches, die Installation dauert wenige Sekunden (weil ihr ja alle immer brav eure Updates macht und nicht 1400 packages updaten müsst, oder? ODER?!)

Wir halten fest: Die Attack-Surface ist schon mal nicht so groß, dass man den Weltuntergang heraufbeschwören müsste und ein Upgrade auf eine gefixte Version ist hinreichend trivial.

Das heißt aber noch nicht, dass es nicht möglich ist, die Schwachstelle auszunutzen. Findige Nerds werden mit ziemlicher Sicherheit den PoC-Exploit aufgreifen, die Offsets (die übrigens innerhalb einer Linux-Distro konsistent bleiben) herausfinden und das Ganze in einen einsatzfähigen Exploit verwandeln. Ich habe ein wenig mit dem Testfile und Ubuntu 2023.4 experimentiert. Die Datei wird klaglos heruntergeladen, wenn man von einer unscheinbaren Website per JS darauf weiterleitet, es handelt sich also tatsächlich theoretisch um einen 0-click Exploit (allerdings müssen die Offsets in der .cue Datei zu der jeweiligen Distro passen).

Sollte der Exploit in Zukunft wirklich weaponized werden, fällt mir als plausible Einsatzmöglichkeit auf die Schnelle eigentlich nur das Browser Exploitation Framework (BeEF) ein, da man über einen hooked Browser zumindest ein paar Infos zum Betriebssystem des unseligen Opfers erhält.

Im Bereich Social Engineering sehe ich nicht wirklich die große Gefahr; es gibt meiner Meinung nach in dem Szenario zuviele Variablen, was den Empfänger betrifft (benutzt dieser überhaupt Linux bzw. eine verwundbare Distro, wenn ja welche, wie müssen die Offsets dafür aussehen, etc.).

Watering-hole attacks könnte ich mir vorstellen, allerdings hielte sich der Impact da wohl in engen Grenzen. Die Website, auf der ich per XSS den Drive-By-Download einschleuse muss entsprechend unsicher sein, das Opfer muss eine verwundbare Linux-Distro verwenden, ich als Angreifer müsste den Callback zeitnah mitbekommen usw. IMHO rein opportunistisches Script-Kiddie-Stuff.

Fazit: Alles halb so wild, einen funktionierenden Exploit würde ich definitiv in mein Arsenal aufnehmen aber hauptsächlich deswegen, weil "haben" besser ist als "brauchen". Das heißt nicht, dass man die Schwachstelle ignorieren sollte. Just patch and move on.

Dabei ist zu beachten, eine Linux-Distro zu verwenden, die noch aktiv supported (kein EOL) ist. Ja, ich weiß, ist naheliegend aber wir wissen alle, dass das durchaus vorkommt.

Über Packages, für die ein Upgrade verfügbar ist kann man sich auf Debian-Derivaten mit apticron per Mail informieren lassen oder diese einfach mit unattended-upgrades automatisch aktuell halten und sich auf die (proverbiale) faule Haut legen.

Und weil Ubuntu + GNOME eine der meistverbreitetsten verwundbaren Distros ist, gibt es das Kommando zum updaten quasi als kleines Dankeschön, dass ihr euch mein Geschwurbel bis zum bitteren Ende angetan habt:

sudo apt update && sudo apt upgrade

PS: Wo wir die Schwachstelle sicher sehen werden, wird in den einschlägigen CTFs sein und darauf freue ich mich schon.