CVE-2022-0847-Dirty-Pipe-

dies ist ein Repository, das ein Eskalationsproblem in einem Linux-System behandelt und Nachrichten zum Problem der „Dirty Pipeline“ enthält

Max Kellermann, ein Entwickler bei CM4all (einem deutschen Webhosting-Unternehmen), entdeckte es Anfang 2022, jedoch nicht durch die Suche nach Schwachstellen. Er war beim Debuggen, als er erfuhr, dass der Kunde unzufrieden damit war, dass die Logs auf ihrem Server spontan korrumpiert wurden. Kellermann verbrachte Monate damit, die Ursache zu verfolgen. Seine Arbeit führte ihn schließlich tief in die Handhabung von Pipes und Page Cache im Linux-Kernel. Er erkannte, dass der von ihm gefundene Fehler, der die Log-Korruption erklärte, tatsächlich etwas weitaus Ernsteres war – eine vollständige Privilegieneskalations-Schwachstelle (Eine vollständige Privilegieneskalations-Schwachstelle ist ein kritischer Sicherheitsfehler, der es einem Angreifer mit niedrigen Rechten – wie einem normalen Benutzer, Gast oder einer unprivilegierten Anwendung – ermöglicht, administrative, Superuser- oder Root-Kontrolle über ein System zu erlangen. Dies bedeutet, dass der Angreifer alle beabsichtigten Sicherheitsgrenzen umgeht und ihm vollständige Kontrolle gewährt, um Systemdateien zu ändern, Software zu installieren, Daten zu stehlen oder Dateien zu löschen). Er meldete es verantwortungsvoll an das Linux-Kernel-Team und Linus Torvalds persönlich. Es wurde innerhalb weniger Tage gepatcht. Das eigentliche Problem ist – wenn splice() Daten in eine Pipe überträgt, vergisst es, dieses Flag auf dem Zielpuffer zu löschen. Daher hatte die gesplicete Seite (die direkt auf den schreibgeschützten Page Cache einer Datei verweist) immer noch CAN_MERGE gesetzt. Wenn Sie nun in diese Pipe schreiben, sieht der Kernel CAN_MERGE, nimmt an, dass die Seite beschreibbar ist, und fügt Ihre Daten direkt in den Page Cache ein – das ist der Speicherinhalt der Datei – ohne jede Berechtigungsprüfung. Ergebnis: Sie können den Inhalt jeder Datei überschreiben, die für Sie lesbar ist, einschließlich SUID (set user ID) Root-Binärdateien wie su, passwd, sudo. Warum war der Fehler so wichtig? Einige Gründe:

1. Er umging DAC vollständig – die diskretionäre Zugriffskontrolle (Dateiberechtigungen, Eigentümer) war völlig außer Kraft. Der Kernel fragte nie: „Hat dieser Benutzer Schreibberechtigung?“
2. SUID-Binärdateien sind das perfekte Ziel – Dateien wie /usr/bin/passwd laufen als Root, unabhängig davon, wer sie aufruft. Patche sie → sofortiger Root-Zugriff. Dadurch können Angreifer root-ähnliche Kontrolle erlangen.
3. Jede Datei im Page Cache, nicht nur Binärdateien. Sie könnten Protokolle, Konfigurationsdateien usw. beschädigen.