Im Bereich der IT-Sicherheit spielen lokale Informationslecks eine gefährliche Rolle, vor allem wenn sie in zentralen Komponenten von Betriebssystemen wie Linux auftreten. Zwei solcher kritischen Schwachstellen wurden jüngst in den Core-Dump-Handlern apport und systemd-coredump entdeckt. Die Analyse dieser Lecks zeigt, wie durch ausgeklügelte Angriffe sensible Daten wie Passwort-Hashes aus dem Speicher von privilegierten Programmen erlangt werden können. Die Problematik erstreckt sich dabei auf wichtige Distributionen wie Ubuntu, Fedora und Red Hat Enterprise Linux, womit eine breite Basis von Servern und Arbeitsstationen betroffen ist. In der vorliegenden Zusammenfassung wird die Komplexität dieser Sicherheitslücken beleuchtet, um Anwender für die Risiken zu sensibilisieren und praktische Schutzmaßnahmen nahezubringen. Die Kernverletzlichkeit beruht auf einem sogenannten Race Condition, einer Wettbewerbssituation bei der Ausführung von Prozessen.
Konkret bedeutet dies, dass ein lokaler Angreifer ein privilegiertes Programm zum Absturz bringen kann, wodurch ein Core-Dump erzeugt wird. Normalerweise sind solche Dumps hochsensibel und sollten weder für unautorisierte Benutzer zugänglich noch einfach zu manipulieren sein. Das Problem entsteht jedoch, weil ein Angreifer in der kurzen Zeitspanne nach dem Crash das abgestürzte Programm durch einen eigenen Prozess ersetzen kann – bevor die Core-Dump-Handler apport oder systemd-coredump die relevanten Prozessdateien auswerten. Dadurch gelingt es dem Angreifer, eine falsche Ansicht des Prozessstatus zu präsentieren und somit Zugriff auf die eigentlich geschützten Memory-Dumps des ursprünglichen Programms zu erhalten. Ein prägnantes Beispiel sind Programme mit SUID- oder SGID-Rechten, die besonders sensible Daten im Speicher halten. Ein exemplarisch genutztes Tool ist unix_chkpwd, das standardmäßig auf vielen Linux-Systemen als SUID- oder SGID-Prozess installiert ist.
Es wird für die Authentifizierung verwendet und lädt daher Passwort-Hashes aus der Datei /etc/shadow in den Arbeitsspeicher. Indem ein Angreifer gezielt diesen Prozess abstürzen lässt und anschließend durch eine geschickte Prozessmanipulation den Core-Dump abfängt, kann er diese hochsensible Information auslesen. Der dabei ausgenutzte Thread des Betriebssystems, Prozesse anhand der Prozess-ID (PID) über /proc zu verwalten, wird zum entscheidenden Angriffspunkt. Die Schwachstelle in apport wurzelt in einer unsauberen Reihenfolge von Sicherheitsüberprüfungen. Obwohl bereits einige Mechanismen zur Verhinderung von PID-Recycling-Angriffen implementiert wurden, zeigte sich, dass nicht alle Codepfade konsequent abgesichert sind. Insbesondere wird die Funktion, die für das Weiterleiten und Überprüfen von Prozessen in Container-Namespaces zuständig ist, vor der Durchführung der finalen Konsistenzprüfung aufgerufen.
Das ermöglicht dem Angreifer, die Auswertung soweit zu beeinflussen, dass apport die Core-Datei eines nicht abgängigen Prozesses analysiert, wodurch eigentlich geschützte Informationen öffentlich gemacht werden können. Die Komplexität des Angriffs erhöht sich durch notwendige Timing-Anforderungen. Ein erfolgreicher Angriff muss sichergehen, dass der SUID-Prozess im richtigen Zustand abstürzt, also dass die geheimen Daten bereits im Speicher geladen, jedoch noch nicht überschrieben sind. Da direkte Überwachungsmechanismen auf Dateien wie /etc/shadow durch fehlende Leserechte ausgeschlossen sind, wurden indirekte Methoden genutzt, zum Beispiel das Beobachten der Datei /etc/passwd – sie wird unmittelbar vor /etc/shadow geöffnet und enthält keine so sensiblen Daten. Die Präzision der Manipulation ist daher enorm hoch, doch die praktischen Experimentierberichte zeigen, dass die Attacke mit guter Erfolgsquote durchführbar ist.
Ein weiterer Kritikpunkt betrifft die Geschwindigkeit, mit der der Angriff auf die Prozesse durchgeführt wird. Einmal abgestürzt, muss der Angreifer den ursprünglichen Prozess durch einen eigenen Prozess mit der gleichen PID ersetzen, was bei modernen Linux-Systemen mit sehr hohem maximalen PID-Wert schwierig sein kann. Eine ausgeklügelte Technik besteht darin, vor dem Absturz eine Vielzahl von Prozessen zu erzeugen, sodass der PID-Zähler quasi voraktiv in Richtung der Ziel-PID getrieben wird. Dadurch kann die PID eines kürzlich beendeten, privilegierten Prozesses schnell wiederverwendet und der Launch des eigenen Ersatzprozesses ermöglicht werden. Solche Prozessflut ist zwar ressourcenintensiv, aber durchaus umsetzbar, wenn die Angriffsbedingungen stimmen. Der Core-Dump-Handler systemd-coredump zeigt vergleichbare Schwächen.
Hier wird zwar geprüft, ob der Benutzer, der den Core-Dump anfordert, berechtigt ist – anhand von Informationen aus /proc/pid/auxv werden die Benutzer- und Gruppen-IDs sowie Sicherheitsflags überprüft. Allerdings findet dieselbe Race Condition statt: Zwischen dem Absturz des SUID-Prozesses und der Auswertung der Nutzerrechte kann der Prozess mit einem nicht privilegierten Prozess ausgetauscht werden, der dieselben User- und Gruppenkontexte besitzt. So erhält ein Angreifer schließlich unerlaubten Zugriff auf Core-Dump-Daten, die sonst für ihn unlesbar wären. Das Ausnutzen dieser Schwachstellen ist technisch anspruchsvoll, stellt jedoch eine bedeutende Gefahr dar, da sie den Zugriff auf hochsensible Systeminformationen ermöglichen.
Beispielsweise wurde in praktischen Tests gezeigt, dass Angreifer auf Passwort-Hashes aus /etc/shadow, private Host-Schlüssel des sshd-Daemons sowie weitere vertrauliche Daten wie Cron-Tabellen und Informationen über Speicher-Layout-Schutzmechanismen (ASLR) zugreifen konnten. Dies kann zu weiterführenden Angriffen wie der Übernahme von Root-Rechten oder der Aushebung der Systemsicherheit führen. Als temporäre Maßnahme zur Schadensbegrenzung kann das Deaktivieren von Core-Dumps für SUID-Programme über die Systemeinstellung /proc/sys/fs/suid_dumpable erfolgen. Mit dem Wert null werden Core-Dumps von privilegierten Prozessen unterbunden, was einen wichtigen Schutz darstellt. Langfristig jedoch ist es nötig, die Core-Dump-Handler selbst zu überarbeiten, um mehrere Schutzmechanismen zu implementieren. Eine wesentliche Verbesserung besteht darin, die Kernel-Optionen für Core-Dump-Pfade klug zu konfigurieren.
So wurde die Einführung des neuen %F-Spezifikators im Pfad /proc/sys/kernel/core_pattern bedeutend. Er ermöglicht, mit einem sogenannten pidfd (Prozess-Identifikator-Dateideskriptor) zu arbeiten, der feststellt, ob der analysierte Prozess durch einen anderen ersetzt wurde. Die Core-Dump-Handler können damit Vorwürfe eines Prozess-Ersatzes erkennen und den Zugriff auf Core-Dumps verweigern, falls eine Manipulation vermutet wird. Zusätzlich muss in allen codebasierten Verarbeitungsalgorithmen der Kernel-Per-Process-Dumpable-Flag berücksichtigt werden. Dieser Flag entscheidet, ob ein Prozess berechtigt ist, einen Core-Dump zu erzeugen und ob dieser für bestimmte Benutzer lesbar ist. Ein Versäumnis in diesem Bereich öffnet Angreifern unnötige Angriffsflächen. Diese Schwachstellen verdeutlichen, wie das Zusammenspiel zwischen Kernel-Funktionen, Core-Dump-Handlern und Prozessmanagement auf niedriger Ebene kritisch für die Systemsicherheit ist.
Auch wenn sich die Exploits technisch nur von privilegierten lokalen Benutzern umsetzen lassen, haben sie weitreichende Auswirkungen auf den Schutz sensibler Betriebsdaten. Insbesondere Systeme, die mit erhöhten Rechten arbeiten oder vertrauliche Informationen enthalten, müssen schnellstmöglich diese Lücken schließen, um Angriffe zu verhindern. Die Entwicklerteams von Ubuntu, Fedora, Red Hat und systemd haben bereits darauf reagiert, Sicherheitsupdates veröffentlicht und arbeiten an langfristigen Korrekturen. In der Zwischenzeit empfehlen Sicherheitsexperten, den Zugriff auf Core-Dumps rigoros zu beschränken, Prozesse mit privilegierten Rechten regelmäßig zu prüfen und das Sicherheitskonzept der Systemeinrichtung zu überprüfen. Innovative Features wie der pidfd-basierte %F-Spezifikator sind bereits in Linux-Kernel integriert und finden zunehmend Anwendung in Kernkomponenten, um diese Klassen von Race Conditions zu eliminieren.
Die kontinuierliche Überprüfung und Anpassung dieser Mechanismen bleibt jedoch unerlässlich, da sich Angreifer stets neue Schwachstellen und Techniken erarbeiten. Insgesamt ist das Thema ein eindrückliches Beispiel für das Spannungsfeld zwischen Funktionalität, Performance und Sicherheit bei Betriebssystemkomponenten. Die Entdeckung und Veröffentlichung dieser lokalen Informationslecks sensibilisiert die Community und motiviert zur dauerhaften Verbesserung von Sicherheitsprotokollen. Für Systemadministratoren und Entwickler ist es entscheidend, die Hintergründe dieser Schwachstellen zu verstehen, um ihre Systeme gegen solche komplexen, intelligenten Angriffe zu schützen und sich mit aktuellen Sicherheitsstandards auseinanderzusetzen.
