[Wornat1959]

29.10.2018 14:23 Uhr 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 Michael Plura


Über die Sicherheitslücke [ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ] 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, [ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]. 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 [ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ] 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 [ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ] 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. Zur Not könnten Nutzer X starten und laufen lassen – ein Angreifer kann es nicht ein zweites Mal starten.

Zu frühes Release?
OpenBSD-Gründer Theo de Raadt [ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ], dass seiner Meinung nach Red-Hat-Mitarbeiter 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 [ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ] zwei Wochen vor dem angekündigten Termin veröffentlichte – und daher den Bug in der Standardinstallation ausliefert. (Michael Plura) / (fo)

Quelle: [ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]

Mein Gentoo hat den Bugfix schon ...