Dirty Pipe: Kritische Sicherheitslücke in Linux und Android gestopft

Seit der Freigabe des Kernel 5.8 am 3. August 2020 steckte in Linux und Android eine kritische Sicherheitslücke (CVE-2022-0847), welche das Überschreiben beliebiger schreibgeschützter Dateien ermöglichte. Selbst schreibgeschützte Partitionen waren vor diesem Angriff nicht gefeit, so dass ein Angreifer ohne besondere Rechte das ganze System übernehmen konnte. Glücklicherweise werden die passenden Updates schon seit andere Geräte erreichen werden, steht wie üblich in den Sternen.

Die Entdeckung von Dirty Pipe
Der Software-Entwickler Max Kellermann hatte am 19. Februar 2022 bei der Untersuchung eines Fehlers eine kritische Sicherheitslücke im Linux-Kernel gefunden und am Folgetag einen Fehlerbericht samt Exploit-Code und Patch beim Linux-Kernel-Team eingereicht. Einen weiteren Tag später konnte Kellermann das Problem auch auf einem Google Pixel 6 nachstellen und informierte das Android-Sicherheitsteam. Mit den am 23. Februar 2022 veröffentlichten Kernel-Updates 5.16.11, 5.15.25 und 5.10.102 wurde die Schwachstelle geschlossen. Einen weiteren Tag später wurde die Korrektur auch in Android übernommen. Gestern, am 7. März 2022, wurde der Fehler, welcher inzwischen auf den Namen Dirty Pipe (CVE-2022-0847) hört, offengelegt.

Kaputte Archive als Symptom
Tatsächlich wurde das Problem bzw. die für Nutzer sichtbaren Auswirkungen schon knapp zehn Monaten früher, am 29. April 2021, erstmals gemeldet. Betroffen waren die Log-Dateien eines Web-Servers, welche sich GZ-komprimiert herunterladen lassen. Sporadisch waren diese GZ-Archive allerdings fehlerhaft und ließen sich nicht entpacken. Bei einer näheren Untersuchung stellte Kellermann fest, dass die Log-Datei selbst intakt war, aber die Prüfsumme (CRC32) und die Dateigröße nicht dazu passten. Erstaunlicherweise wiesen alle defekten Dateien die selbe CRC32-Prüfsumme und die selbe Dateilänge auf. Irgendwann fiel Kellermann dann auf, dass diese immer wieder auftauchenden 8 Bytes dem abgeschnittenen Anfang einer ZIP-Datei entsprechen. Wie sich zeigte, hatte ein ganz anderer Prozess, der keinerlei Schreibzugriff für die fehlerhaften GZ-Archive hatte, die 8 Byte dort platziert. Und der Auslöser war ein Fehler im Kernel-Code.

Rohrpost für Prozesse
Seit dem Jahr 1973 verwenden Unix-basierte Systeme Pipes zur Kommunikation zwischen Prozessen. Pipes sind dabei Einbandstraßen: Auf einer Seite gehen Daten hinein, auf der anderen kommen sie wieder heraus. Verwendet werden hierbei 4 KiB große Speicherseiten und wenn ein Schreibzugriff die Seite nicht ganz füllt, kann ein folgender Schreibzugriff seine Daten anhängen (anonyme Pipe-Puffer). Will man Dateien durch eine Pipe schicken, nutzt man dafür splice() und umgeht ein speicherintensives Hin- und Herschieben zwischen dem Kernel- und dem Benutzerraum (zero copy). Der Linux-Kernel lädt diese Daten zunächst in einen Page Cache (eine Zwischenspeicherung im Arbeitsspeicher) und verweist dann mit einem Pipe-Puffer in diesen Speicherbereich. Kommen weitere Daten aus der Pipe, dürfen diese nicht einfach angehängt werden, denn die Seite gehört dem Page Cache und nicht der Pipe.

Ein Fehler in der Pipe
Im Jahr 2016 wurde es möglich, Page-Cache-Referenzen mit beliebigen Flags zu erstellen, doch es wurde vergessen, diese zu initialisieren. Zum Problem wurde das aber erst 2020, als PIPE_BUF_FLAG_CAN_MERGE eingeführt wurde, denn nun ließ sich der Page Cache mit neuen Daten aus der Pipe überschreiben. Unter bestimmten Umständen konnten somit Teile einer per splice() übergebenen Datei verfälscht werden. Bis zu diesem Zeitpunkt ist der Fehler noch vergleichsweise harmlos, denn der Page Cache ist flüchtig und wird gelöscht, sobald er nicht mehr benötigt oder das Gerät neu gestartet wird. Erst wenn der Kernel annimmt, dass die Daten im Page Cache verändert wurden, man spricht auch von modifiziert oder dirty, werden diese zurück auf den Datenträger geschrieben. Wenn dies geschieht, wird die Datei selbst verfälscht und somit beschädigt.

Und jetzt wird es heikel
Beim Zurückschreiben der Daten auf den Datenträger spielen die Schreibrechte keine Rolle. Unter Linux müssen im Page Cache veränderte Daten grundsätzlich zurückgeschrieben werden, selbst auf schreibgeschützte Partitionen oder eingebundene CD-ROM-Abbilder! Zugleich werden keine Berechtigungen abgefragt, denn eigentlich werden ja nur Daten in eine Pipe geschickt. Ein unverblümt direkter Angriff bestünde darin, als einfacher Benutzer das Passwort des Root-Nutzers zu überschreiben und sich damit die volle Kontrolle über das System zu verschaffen. Auch der Ansatz von Linux und Android, mit einer schreibgeschützten Systempartition zu arbeiten, wird auf diese Weise vollständig unterminiert. In vielen Punkten erinnert Dirty Pipe (CVE-2022-0847) an Dirty Cow (CVE-2016-5195), doch der neue Fehler benötigt kein präzises Timing und lässt sich daher viel einfacher ausnutzen.