Linux-Kernel wieder von Bug geplagt

Auf der Entwickler-Nachrichtenseite ‘Bugtraq’ wurde es erstmals bekannt: Eine neue, kritische Sicherheitslücke in der Speicherverwaltung des Kernels erlaubt es lokalen Angreifern, Root-Rechte zu erlangen. Das hat der Sicherheitsexperte Paul Starzetz   veröffentlicht. Betroffen sei demnach neben Kernel Version 2.2 und 2.4 auch der erst vor kurzem freigegebene Kernel 2.6, der laut den Distributoren erst in einigen Monaten als lauffähige Geschäftsanwendung verfügbar sein soll.
Verantwortlich für das neue Sicherheitsproblem sei eine ungenügende Überprüfung in der Funktion do_mremap, die zum Anpassen des virtuellen Speichers dient. Wie es weiter heißt, würden beim Remapping des Speichers die Parameter unzureichend überprüft, wodurch ein virtueller Speicherbereich von Null Byte Länge erzeugt werden könne. Da noch weitere Probleme in der Funktion do_mremap bestehen, könnten somit weitere Probleme in der Speicherverwaltung des Kernels verursacht werden. In jedem Fall sei aber die Sicherheitslücke nur für einen lokalen Angriff geeignet. Es sei also zumindest der Zugriff auf eine Shell notwendig.

Für die Verwendung des nötigen mremap-Systemaufrufs sind der Meldung zufolge keine bestimmten Rechte erforderlich. Theoretisch könne daher jeder Prozess dieses Verhalten ausnutzen und eigenen Code mit Root-Rechten ausführen. Laut Starzetz gebe es bereits einen Exploit, der jedoch bisher noch nicht veröffentlicht sei. Starzetz rät daher dringend dazu, Patches einzuspielen, um dieses Problem zu beheben.

Die Kernel-Entwickler arbeiten bereits an einem Patch. Für die 2.4-er Reihe steht der neue Kernel 2.4.24 bereit, der den Fehler behebt. Ferner hat Red Hat aktualisierte Kernel-Pakete für alle Red Hat Linux Versionen ab 7.1 zur Verfügung gestellt. Im November 2003 hatte eine Sicherheitslücke im Kernel dazu geführt, dass die Server des Debian-Projektes gecrackt wurden. Dabei war die Funktion do_mmap für die Probleme verantwortlich.

Entwickler Christophe Devine hat parallel dazu auf der Mailingliste ‘Full-Disclosure’ einen Exploit für den kürzlich gemeldeten do_remap-Fehler im Linux-Kernel veröffentlicht. Der C-Code besteht gerade einmal aus 16 Zeilen und bringt, lokal ausgeführt, ungepatchte 2.4er- und 2.6er-Systeme zum Absturz. In den Versionen 2.4.24 und 2.6.1-rc2 sind die Fehler beseitigt. Einige ungepatchte, aber besonders sicher konfigurierte Systeme sollen ebenfalls gegen den Exploit immun sein, wie es heißt.

Der Großteil der Linux-Distributoren und Hersteller von Appliances, die auf Linux aufsetzen, hat mittlerweile Updates zur Verfügung gestellt. Anwender, die den Patch, der nur aus wenigen Zeilen besteht, manuell in ihre Kernel-Sourcen eingefügt haben, können mit dem Exploit überprüfen, ob ihre Systeme noch verwundbar sind. Von einem Test in Produktionsumgebungen sollte man allerdings Abstand nehmen.

Einstweilen diskutieren die Nutzer die neueste Nachricht durchaus konträr. Während ein Linux-Anwender im Diskussionsforum des Magazins Pro-Linux von der Schnelligkeit schwärmt, es gebe eben nur bei Linux den Patch nahezu zeitgleich mit der Fehlermeldung, sind andere eher skeptisch. So sei, moniert ein Nutzer, die Lücke im Kernel 2.4 bereits monatelang bekannt gewesen. Auch früher schon, so schreibt er, habe sich der Entwickler Tosatti, der Maintainer des 2.4er Kernels geweigert, ein Kernel-Sicherheitsupdate herauszubringen und abgewartet, bis Distributoren den Patch integriert hätten. Das widerlegt ein anderer und weist darauf hin, dass die Patches bei Linux-Entwicklungen immerhin schneller als bei Microsoft auf den Tisch kämen.

Doch schließlich fasst einer der Diskutierenden das Credo der Linux-Gemeinde noch einmal in einfachen Sätzen zusammen und stellt so die Einheit in der Gemeinde wieder her: “Software wird als Werkzeug für Menschen geschrieben, um Ihnen bei bestimmten Aufgaben zu helfen. Die ideale Software würde dies dann irgendwann umfassend können. Jeder Software Entwickler der versucht, dieses Ideal zu erreichen, wird seine Software konsequent weiterentwickeln müssen. Es würde am Ende nicht wundern, wenn am Anfang unterschiedliche Modelle sehr ähnlich seien, da sie sich im Rahmen der Software-Evolution ja immer dem gleichen Ziel nähern: dem Anwender das optimale Werkzeug zur Bewältigung seiner Aufgaben zur Verfügung zu stellen.” Noch Fragen?