Open Source im professionellen Einsatz
Linux-Magazin 09/2006
© photocase.com

© photocase.com

Sicheres Programmieren für Administratoren - Folge 7: Sicherheitslücken in X.org

Düstere Aussichten

Monatlich berichtet das Linux-Magazin in den "InSecurity News" über Sicherheitslücken. Was hinter den misslichen Meldungen steckt, beleuchtet dieser Artikel am Beispiel dreier Probleme im X11-Server von X.org.

1053

Der Unterhaltungswert der Rubrik InSecurity News ist selbst für anspruchslose Leser begrenzt. Sie arbeitet mit trockenen Begriffen wie "Buffer Overflow", "Format-String-Fehler" und "Cross-Site-Skripting", "Denial of Service" oder "Angreifer kann Befehle ausführen". Hinter den nachrichtlich-nüchternen Formulierungen verbergen sich manchmal originelle und lehrreiche Exemplare misslungener Software-Entwicklung.

Diesen Schatz an Erfahrungen will die folgende Fallstudie heben - am Beispiel von X. Die Meldungen aus den InSecurity News der Ausgaben 6/06, 7/06 und 9/06 geben den Anlass, die aktuelle X11-Distribution von X.org als Untersuchungsobjekt zu wählen (siehe Kasten "InSecurity-Meldungen").

InSecurity-Meldungen

In den Ausgaben 6/06 und 7/06 sowie in dem vorliegenden Linux-Magazin melden die "InSecurity News" drei Lücken im X-Server von X.org. Die Hintergründe und Details beschreibt der vorliegende Artikel.

Lücke 1: Linux-Magazin 9/06

In den aktuellen InSecurity News berichtet eine Meldung über eine Lücke im X-Server von X.org im Zusammenhang mit mangelhaften Set-UID-Aufrufen. Das Original-Advisory findet sich im X.org-Wiki. [http://wiki.x.org/wiki/SecurityPage]

Lücke 2: Linux-Magazin 7/06

X-Server: Buffer-Overflow in der Render-Extension »render/mitri.c«, entfernter Angreifer kann Befehle ausführen. [http://securitytracker.com/alerts/2006/May/1016018.html]

Lücke 3: Linux-Magazin 6/06

Aufgrund einer Schwachstelle im X11-Server von X.org kann sich ein lokaler Angreifer Root-Rechte verschaffen. Der Server verarbeitet die beiden Kommandozeilenargumente »-modulepath« und »-logfile« fehlerhaft. Der Angreifer kann dies ausnutzen, um eigenen Code in den Server einzuschleusen. Ein einfacher Exploit findet sich unter [http://www.securiteam.com/exploits/5HP0L0KI0Q.html]. Betroffen von dieser Schwachstelle sind die X.org-Server-Versionen 1.0.0 und älter sowie X11R6.9.0 und X11R7.0. [http://securitytracker.com/alerts/2006/Mar/1015793.html]

X11-Oberflächen haben sich in der Unix-Welt etabliert. Ihre Netzwerkfähigkeit erweist sich gerade im professionellen Bereich als unentbehrliche Hilfe: Da X11 die Hardware (verwaltet vom X-Server) strikt von den Applikationen (X-Clients) trennt, ist es leicht, Programme aus der Ferne zu bedienen (Abbildung 1).

Abbildung 1: Die X-Anwendung auf Birne und ein ferner X-Server auf Apfel sprechen miteinander via Server-Port 6000. Der Client sendet Grafikanweisungen und andere Anfragen per X11-Protokoll zum Server. Der revanchiert sich mit entsprechenden Antworten und Events. Zudem steuert er die Hardware.

Auf der Schattenseite steht ein Sicherheitskonzept aus der Steinzeit der IT. Nachträglich aufgeschraubte Mechanismen wie MIT-Magic-Cookies und Tunnel via SSH ändern daran wenig. Folge 5 der "Sicheres Programmieren"-Serie skizzierte den Einbruch in einen mit SSH geschützten Server [3]. Der einzige Weg, um das Protokoll komplett abzusichern, wäre, auf Netzwerkfähigkeit und Mehrbenutzersystem zu verzichten.

Stein des Anstoßes

Selbst dann bestehen X und alle X-Applikationen aus Code, den findige Hacker gerne angreifen. Das leuchtet für den X-Server und die zugehörigen Gerätetreiber unmittelbar ein; weniger offensichtlich ist es für die mitgelieferten Bibliotheken wie die »libXpm«, die Routinen zur Verwaltung von Bildern im XPM-Format bereitstellt. Auch heute noch läuft der X-Server auf vielen Systemen mit Set-UID-Root-Bit. Diese Tatsachen und die hohe Verbreitung machen X zu einem attraktiven Angriffsziel.

Wer sich die Mühe macht, den im Kasten angegebenen Links zu folgen, stößt bald auf eine Wiki-Seite mit Security Advisories der X.org Foundation [4]. Die Seite macht einen gepflegten und übersichtlichen Eindruck mit Verweisen auf die Advisorys sowie Aussagen zu den betroffenen Versionen und verfügbaren Patches. Wie schnell sich neue Lücken öffnen, erlebte der Autor während der Arbeit an diesem Artikel: Die Foundation trug die dritte Meldung ein, während der Text bereits im Entstehen war. Das hatte deutliche Auswirkungen auf den Umfang dieses Beitrags.

Lücke 1: Set-UID

Am 20. Juni wies Matthieu Herrb auf der X.org-Mailingliste von Freedesktop.org auf eine Sicherheitslücke in den X.org-Versionen 6.7.0 bis 7.1 hin (Beschreibung und Patches auf [5]). Auf manchen Systemen sind einige Programme aus dem Lieferumfang von X.org mit Set-UID-Root-Rechten installiert. Üblich ist das für den X-Server, aber auch andere Tools unterscheiden zwischen normalen Benutzern und Root. Das Advisory nennt den Display-Manager XDM sowie Xterm; hinzu kommen unter anderem Xload und Xinit. Listing 1 zeigt einen Auszug aus der Datei »os/utils.c« der neuesten Version X11R7.1 des X-Servers.

Listing 1: X.org 7.1,
»os/utils.c«

01 /*
02  * "safer" versions of system(3), popen(3) 
03  * and pclose(3) which give up all privs 
04  * before running a command.
05  * 
06  * This is based on the code in FreeBSD 2.2 
07  * libc.
08  * 
09  * XXX It'd be good to redirect stderr so 
10  * that it ends up in the log file as well. 
11  * As it is now, xkbcomp messages don't end 
12  * up in the log file.
13  */
14 
15 int
16 System(char *command)
17 {
18   int pid, p;
19   void (*csig)(int);
20   int status;
21 
22   if (!command)
23     return(1);
24 
25   csig = signal(SIGCHLD, SIG_DFL);
26 
27   ErrorF("System: `%s'n", command);
28 
29   switch (pid = fork()) {
30   case -1: /* error */
31     p = -1;
32   case 0: /* child */
33     setgid(getgid());
34     setuid(getuid());
35     execl("/bin/sh", "sh", "-c", command, (char *)NULL);
36     _exit(127);
37   default: /* parent */
38     do {
39       p = waitpid(pid, &status, 0);
40     } while (p == -1 && errno == EINTR);
41 
42   }
43 
44   signal(SIGCHLD, csig);
45 
46   return p == -1 ? -1 : status;
47 }

Die mit großem Anfangsbuchstaben geschriebene Funktion »System()« soll eine ähnliche Aufgabe erfüllen wie der Systemaufruf »system()«, der eine Shell startet und darin einen Befehl ausführt. Dazu erzeugt er einen Tochterprozess und führt den Mutterprozess erst dann fort, wenn der Befehl endet (Abbildung 2). Auch wenn der Kommentar am Beginn der Funktion »System()« etwas mehrdeutig ausfällt: Die neue Funktion soll im Gegensatz zu »system()« auch noch die Root-Rechte abgeben, bevor der Befehl läuft.

Abbildung 2: Der »system()«-Aufruf (1) erzeugt einen Tochterprozess mit »fork()« (2) und wartet auf dessen Ende (3). Inzwischen startet die Tochter per »exec()« eine Shell und übergibt ihr das Kommando (4). Nach dem Ende des Tochterprozesses (5) erwacht die Mutter (6).

Alle Schritte aus Abbildung 2 finden sich auch in Listing 1. Dem Einsprungspunkt des Syscall entspricht die Funktion selbst (ab Zeile 16). In Zeile 29 ruft sie Fork auf. Während der Mutterprozess wartet (Zeilen 38 bis 40), führt die Tochter eine Shell aus (»execl()« in Zeile 35).

Neu sind aber die Aufrufe »setgid (getgid())« und »setuid(getuid())«. Sie überschreiben reale, effektive und gespeicherte (saved) User- und Group-IDs und verhindern damit, dass sich die Shell diese Rechte wieder zurückholen kann. Das ist hier besonders wichtig, weil der X-Server die von außen hereingereichte Umgebung nicht bereinigt. Die Shell erbt auch gefährliche Umgebungsvariablen wie »IFS« oder »ENV«, über die sie ein Aufrufer dazu zwingen kann, beliebige Befehle abzuarbeiten (siehe erste Folge [1]). Hat die Shell Root-Rechte, ist der Rechner kompromittiert.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 6 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • X-Server schon bald ohne Root-Rechte?

    Der bei Red Hat angestellte David Airlie berichtet in seinem Blog, dass er durch einen kleinen Hack im Laufe eines Nachmittags einen X-Server ohne Root-Rechte zustande brachte.

  • Lokale Schwachstellen in X.org

    Die Sicherheitsdienstleister iDefense und Secunia haben eine ganze Reihe lokaler Schwachstellen im X-Server von X.org und darauf basierenden Anwendungen veröffentlicht. Insgesamt sieben Lücken melden die Experten.

  • Sicherheitsschwächen in X-Clients

    Ein Security-Experte hat im Code von X11-Client-Bibliotheken eine Menge von Fehlern gefunden, die sich unter Umständen von Angreifern ausnutzen lassen.

  • X-Server in neuer Version 1.7.0

    Das X.org-Team hat den X-Server 1.7.0 zum Download freigegeben. X.org 7.5 kommt demnächst, in Zukunft wird es zudem feste Release-Zyklen geben.

  • X-Server 1.11.0 - Stabilere Basis

    In Version 1.11.0 des X-Servers haben die Entwickler von X.org jede menge Korrekturen einfließen lassen.

comments powered by Disqus

Ausgabe 10/2016

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.