Menü
Update iX Magazin

Aufgesperrt: Root-Rechte mit X.Org

Ein Fehler eines alten Patches entfernt eine Sicherheitsabfrage beim Start von X.Org. So kann jeder Nutzer alle Systemdateien überschreiben.

Von
vorlesen Drucken Kommentare lesen 56 Beiträge
Sicherheitslücke: Root-Rechte mit X.Org

Ü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.

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.

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.

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. (Michael Plura) / (fo)