Aufgesperrt: Root-Rechte mit X.Org

Inhaltsverzeichnis

Über die Sicherheitslücke CVE-2018-14665 können unprivilegierte Nutzer mit X.Org eigenen Code als Modul ausführen und systemweit Dateien überschreiben – mit vollen Root-Rechten. Dass sich so auch die Passwortdatei von Linux und OpenBSD manipulieren lässt, zeigt ein simpler Tweet. X.Org ist ein bei Linux- und BSD-Systemen eingesetzter Displayserver, mit dem die Systeme die grafische Oberfläche darstellen.

Ein verhängnisvoller Patch

Der hierfür verantwortliche Patch stammt von Emil L. Velikov und ist auf den 2. Mai 2016 datiert – ist also schon über 30 Monate alt. Adam Jackson von Red Hat hat den Code überprüft und zwei Tage später freigeschaltet. Die Sicherheitslücke betrifft somit X.Org-Server ab Version 1.19.0

Aufgrund der Änderung überprüft das System nicht mehr korrekt, ob es X.Org mit erweiterten Rechten startet. Dies ist bei einigen Linux-Distribution und OpenBSD jedoch der Fall, da X.Org dort mit Setuid, also Root-Rechten, versehen ist. Übergibt ein Angreifer X.Org via -modulpath eigenen Code, führt es diesen mit den Rechten des X-Servers aus.

Einfacher ist die Umleitung der X.Org-Logdatei über -logfile. Da die Datei mit Root-Rechten geschrieben wird und an jeder Stelle des Dateisystems angelegt werden kann, lassen sich so beliebige Systemdateien überschreiben. Übergibt man X.Org dabei noch schadhaften Code über eine zusätzliche Option wie -fp (eigentlich Fontpath), wird dieser als ungültig erkannt und der Pfad – und hier der Code – in der Logdatei als Fehler gespeichert. Je nachdem, wie das System Konfigurationsdateien auswertet, kann der Angreifer das ausnutzen, um Root-Rechte zu erlangen. Dazu überschreibt er die Datei /etc/shadow und übergibt als Fontpath eine Zeile mit einem Root-Passwort ohne Passwort.

Schnelltest für Xorg

Wie können Nutzer ihr eigenes System überprüfen? Falls es möglich ist, mit einem unprivilegierten Benutzerkonto über

cd /etc
Xorg -logfile test

eine Datei anzulegen, ist das System gefährdet:

-rw-r--r--  1 root  wheel  47572 Oct 29 11:27 test

Allerdings ist bereits ein Bugfix erschienen und sollte als Sicherheits-Update bei betroffenen System verfügbar sein. Unter OpenBSD 6.3/6.4 installiert man zum Beispiel den Fix per syspatch, der vorige Versuch führt anschließend zu einem Fehler:

(EE) Fatal server error:
(EE) Invalid argument -logfile with elevated privileges

Sollte ein Fix nicht verfügbar sein, können Administratoren bei betroffenen Systemen das Setuid-Bit von X.Org per chmod u-s /usr/X11R6/bin/Xorg entfernen. Allerdings funktioniert so startx nicht mehr. Infolgedessen müssen sie ~/.xinitrc und ~/.xsession entfernen und X über xenodm starten.

Zu frühes Release?

OpenBSD-Gründer Theo de Raadt beklagte sich darüber, dass seiner Meinung nach CNRS/LAAS-Mitarbeiter und X.Org- sowie OpenBSD-Entwickler Matthieu Herrb die Informationen über den eher trivialen Fehler zwei Wochen zurückhielt. Einige Betriebssystementwickler hätte er angeblich vorab informiert, das OpenBSD-Team hätte jedoch nicht dazu gehört. Der Ärger hierüber rührt auch daher, dass de Raadt OpenBSD 6.4 zwei Wochen vor dem angekündigten Termin veröffentlichte – und daher den Bug in der Standardinstallation ausliefert.

Update 09:10, 30.10.2018: Im Ursprungstext hieß es, ein mehrfaches Starten von X.Org sei nicht möglich. Jedoch können Nutzer neue Displays beliebig oft starten. X zu starten und laufen zu lassen, schützt das System nicht. (fo)