Core Dumps sind Abbildungen der Speicherbereiche eines abgestürzten Prozesses, die wertvolle Einblicke ermöglichen, um die Ursachen eines Programmfehlers zu analysieren. Historisch gesehen war die Herstellung von Core Dumps eine Routineaufgabe von Unix-Systemen, die nach einem Programmabsturz eine sogenannte core-Datei im aktuellen Arbeitsverzeichnis ablegten. Im modernen Linux-Umfeld hat sich das Verfahren zwar geändert, jedoch bleibt die Erstellung und Verarbeitung von Core Dumps eine zentrale Funktion, die allerdings immer wieder eine Quelle von Sicherheitslücken darstellte. Die Kernelversion 6. 16 bringt nun bedeutende Neuerungen, um die Risiken, die aus der Handhabung von Core Dumps resultieren, zu minimieren und zukünftige Common Vulnerabilities and Exposures (CVE) zu reduzieren. Die Hintergründe und Neuerungen in Bezug auf die Core-Dump-Verarbeitung verdienen eine eingehende Betrachtung und Erklärung. Worum genau geht es bei den Problemen rund um Core Dumps?
Ein Core Dump speichert den Zustand eines Prozesses zum Zeitpunkt seines Absturzes – insbesondere die Datenbereiche, nicht jedoch den ausführbaren Programmcode. Dadurch bekommen Entwickler und Systemadministratoren wichtige Informationen, um Fehler zu analysieren. In der Vergangenheit wurden solche Core Dumps meist als Datei mit dem Namen „core“ im aktuellen Verzeichnis des abgestürzten Prozesses angelegt. Diese Praxis führte allerdings zu praktischen Problemen wie der Notwendigkeit, core-Dateien regelmäßig per Cron-Job zu entfernen, und machte den Dateinamen „core“ untauglich für andere wichtige Zwecke. Daher ist es in modernen Systemen üblich, die Erstellung solcher Dateien zu unterbinden oder zu modifizieren. Ein anderer und verbreiteter Ansatz besteht darin, den Kernel so zu konfigurieren, dass er im Fall eines Programmabsturzes einen speziellen Prozess startet, der sich um die Verarbeitung des Kernabbilds kümmert.
Diese Konfiguration passiert über den sogenannten core_pattern-Parameter. Administratoren können durch diesen Mechanismus anweisen, ein Programm oder Skript zu starten, das Core Dumps an einen zentralen Ort sendet, sie analysiert oder Fehlerberichte an Entwickler übermittelt. Gerade durch diese flexible Handhabung entstand jedoch das sogenannte „usermode helper“ (UMH) API, das für die Kernstückproblematik verantwortlich ist. Dieses API hat Sicherheitslücken hervorgebracht, weil der Kernel den Core-Dump-Handler als privilegierten Prozess startet – mit den Rechten des Root-Benutzers und in der Root-Namespace. Dies macht den Core-Dump-Handler zu einem attraktiven Ziel für Angreifer, die durch komplexe Race Conditions versuchen, privilegierte Informationen auszulesen. Ein prominentes Beispiel war eine Schwachstelle, die sich durch das Zusammenspiel von Ubuntu's apport-Tool und systemd-coredump manifestierte.
Angreifer konnten durch geschicktes Management von Prozess-IDs (PIDs) eine Situation ausnutzen, bei der ein abgestürzter Prozess zwischenzeitlich durch einen anderen Prozess mit derselben PID ersetzt wurde. Der Core-Dump-Handler wertete dadurch fälschlicherweise den zweiten Prozess aus, der vom Angreifer kontrolliert wurde, und konnte auf sensible Daten des ursprünglichen Prozesses zugreifen – etwa die Inhalte der Datei /etc/shadow oder private Schlüssel in der SSH-Server-Memory. Das Kernproblem liegt also in der Verwendung von PIDs als zuverlässigem Identifikator von Prozessen. PIDs sind lediglich 32-Bit-Zahlen, die nach dem Tod eines Prozesses wiederverwendet werden können, was zu solchen Sicherheitsproblemen führt. Die Lösung muss deshalb darin bestehen, sicherzustellen, dass der Core-Dump-Handler tatsächlich mit dem abgestürzten Prozess interagiert und nicht mit einem übernommenden Prozess unter gleichen Prozess-IDs. Genau hier setzen die Neuerungen mit Kernel 6. 16 an.
Christian Brauner, der Entwickler hinter diesem Update, stellte einen neuen Mechanismus vor, der es ermöglicht, einen sogenannten pidfd (prozessidentifizierender Dateideskriptor) an den Core-Dump-Handler zu übergeben. Dieser pidfd verweist eindeutig auf den abgestürzten Prozess und ist vor der Art von Angriffsversuchen geschützt, die auf PID-Wiederverwendung basieren. Durch ein neues Formatierungszeichen („%F“) im core_pattern-Parameter kann der Kernel den Core-Dump-Handler mit diesem sicheren Identifikator als Dateibezeichner 3 starten. Diese Lösung ist eine erste Maßnahme, die bereits in stabile Kernel zurückportiert wurde, und erlaubt es vielen Core-Dump-Handlern, bestehende Vulnerabilitäten zu vermeiden. Doch die eigentliche Revolution liegt in einem noch moderneren Konzept.
Statt für jeden Crash ein neues Hilfsprogramm als voll privilegierten Benutzer zu starten, kann der Kernel jetzt Core Dumps direkt über einen UNIX-Socket an einen bereits laufenden, privilegierten Prozess senden. Dieser Nutzerprozess kann sich nach Verbindungsaufnahme seine Rechte auf das absolute Minimum reduzieren und die Daten dauerhaft sicher empfangen. Der Core-Dump-Handler erhält dabei auch hier einen pidfd, der ihn zur eindeutigen Identifikation des abgestürzten Prozesses befähigt. Darüber hinaus erlaubt eine neue Socket-Option zusätzliches Feedback über den aktuellen Status des Prozesses, wodurch weitere Angriffsszenarien unterbunden werden können. Diese socket-basierte Lösung ist ressourceneffizienter, da keine wiederholten Prozessstarts notwendig sind, und deutlich sicherer, weil die Angriffsflächen auf privilegierte Operationen reduziert werden.
Die Verteilung und Nutzung dieses neuen Systems wird allerdings noch einige Zeit in Anspruch nehmen, da Kernel-Patches oft erst dann in Produktivsystemen ankommen, wenn Distributoren sie übernehmen und anpassen. Eine Umstellung wird also schrittweise erfolgen. Die Diskussion um das Kernproblem der Prozessidentifikation durch PIDs wird dabei weitergeführt. Einige Stimmen regen eine Umstellung auf 64-Bit-PIDs oder sogar auf UUIDs für Prozesse an. Letztere würden eine globale und zeitlich unbegrenzte Eindeutigkeit garantieren. Jedoch gestalten sich solche Veränderungen als extrem kompliziert, da PID-basierte Schnittstellen tief in Betriebssystem, Systembibliotheken, Anwendungen und Skripten verankert sind – eine Umstellung auf 64-Bit-PIDs würde massiv Kompatibilitätsprobleme verursachen. Die pidfd-Mechanismen haben hier einen eleganten Zwischenweg geboten: Sie sind rückwärtskompatibel und erlauben dennoch sichere Prozesseindeutigkeit auf Kernel-Ebene.
Im Rahmen der Systemadministration und Sicherheitspraxis bedeutet das eine Verschiebung der Verantwortung weg vom Kernel hin zu dedizierten Nutzungsprozessen, die Crash-Dumps sicher und kontrolliert verarbeiten. Zugleich zeigt sich, dass die klassische Handhabung von Core Dumps mittels Dateien im Dateisystem inzwischen veraltet und fehleranfällig ist. Moderne Systeme tendieren dazu, Kernabbildungen über dedizierte IPC-Mechanismen oder über spezialisierte Daemonprozesse handzuhaben. Manche Softwarearchitekturen, insbesondere im Bereich mobiler Geräte oder großer Cloud-Dienste, setzen sogar vollständig auf Nutzerprozess-gesteuertes Crash-Reporting, um Kernelcode so schlank und sicher wie möglich zu halten. Die im Linux-Kernel 6. 16 realisierten Neuerungen sind daher nicht nur Schritte zur Behebung einer spezifischen Klasse von Sicherheitslücken, sondern ein Wegweiser für die zukünftige Handhabung von Core Dumps.
Diese Entwicklung führt erwartungsgemäß zu robusterer, effizienterer und sicherer Software, die Angriffe ausforscht und verhindert, bevor sie kritisch werden. Die Sicherheitsgemeinschaft begrüßt diese Fortschritte, und es ist davon auszugehen, dass die Verbreitung sicherer Core-Dump-APIs in den kommenden Jahren zur signifikanten Reduktion von CVEs im Linux-Umfeld beiträgt. Für Administratoren und Entwickler bedeutet das auch, sich mit dem neuen API vertraut zu machen und ihre Fehleranalyse- sowie Crash-Management-Tools entsprechend anzupassen. Nachhaltige IT-Sicherheit setzt eben oft in solchen Details an – insbesondere wenn es um so grundlegende Mechanismen wie Prozess-Identifizierung und Crash-Handling geht.
Angesichts der Intensität, mit der Angriffsmöglichkeiten über Core Dumps in den letzten Jahren dokumentiert wurden, ist die nun vorgenommene Modernisierung des Linux-Kernels ein wichtiger Schritt zur langfristigen Abwehr von Exploits und damit zum Schutz der Systemintegrität und der in den Prozessen gespeicherten sensiblen Daten.
