Zurück zur Schwachstellen-Datenbank

Offenlegung von Core-Dump-Datei für unbefugte Kontrollsphäre

Beschreibung

Offenlegung von Core-Dump-Datei für unbefugte Kontrollsphäre ist eine Schwachstelle, bei der ein Produkt Core-Dump-Dateien in einem Verzeichnis, Archiv oder einer anderen Ressource generiert, die für unbefugte Akteure zugänglich ist. Core-Dumps sind Speicher-Snapshots, die erstellt werden, wenn ein Programm abstürzt, und enthalten den vollständigen Prozessspeicherzustand zum Zeitpunkt des Fehlers. Diese Dateien können sensible Informationen wie Verschlüsselungsschlüssel, Passwörter, persönliche Daten, Datenbankinhalte und Anwendungsgeheimnisse enthalten, die zum Zeitpunkt des Absturzes im Speicher vorhanden waren.

Risiko

Core-Dump-Dateien stellen erhebliche Vertraulichkeitsrisiken dar, da sie rohe Speicherinhalte enthalten. Passwörter und Authentifizierungstokens, die nie auf die Festplatte geschrieben wurden, können aus Core-Dumps wiederherstellbar sein. Verschlüsselungsschlüssel, die zum Datenschutz verwendet werden, werden offengelegt. Persönliche Benutzerdaten, die zum Zeitpunkt des Absturzes verarbeitet wurden, werden erfasst. Datenbank-Abfrageergebnisse und Verbindungsstrings können vorhanden sein. Das Risiko wird verstärkt, wenn Core-Dumps in von allen lesbaren Verzeichnissen geschrieben, an zugänglichen Orten auf Webservern gespeichert oder in Fehlerberichten an Dritte gesendet werden. Angreifer, die Zugriff auf Core-Dumps erlangen, können Anmeldedaten und Geheimnisse extrahieren, ohne je die laufende Anwendung zu kompromittieren.

Lösung

Konfigurieren Sie Systeme, um die Core-Dump-Generierung in Produktionsumgebungen wenn möglich zu verhindern, oder beschränken Sie Core-Dump-Dateiberechtigungen und Speicherorte. Verwenden Sie sichere Verzeichnisse mit angemessenen Zugriffskontrollen für Core-Dump-Speicherung. Deaktivieren Sie Core-Dumps für Prozesse, die sensible Daten verarbeiten. Wenn Core-Dumps für Debugging benötigt werden, stellen Sie sicher, dass sie in geschützte Verzeichnisse geschrieben werden, die nicht über Webserver oder andere öffentliche Schnittstellen zugänglich sind. Implementieren Sie automatische Bereinigung von Core-Dump-Dateien. Erwägen Sie die Verwendung von bereinigten Crash-Dumps, die sensible Speicherbereiche ausschließen. Wenden Sie das Prinzip der geringsten Privilegien auf Core-Dump-Dateizugriff an.

Häufige Auswirkungen

AuswirkungDetails
VertraulichkeitBereich: Vertraulichkeit

Anwendungsdaten lesen - Core-Dumps enthalten den vollständigen Speicherzustand des Prozesses und können potenziell Passwörter, Verschlüsselungsschlüssel, persönliche Daten und andere sensible Informationen enthalten.
VertraulichkeitBereich: Vertraulichkeit

Dateien oder Verzeichnisse lesen - Angreifer, die auf Core-Dumps zugreifen, können Daten lesen, die nie zur Speicherung auf der Festplatte bestimmt waren, einschließlich In-Memory-Caches und temporärer Daten.

Beispielcode

Verwundbare Konfiguration

# Verwundbar: Core-Dumps mit permissiven Einstellungen aktiviert
# /etc/security/limits.conf
*               soft    core            unlimited
*               hard    core            unlimited

# Verwundbar: Core-Dumps in von allen lesbares Verzeichnis geschrieben
# /etc/sysctl.conf
kernel.core_pattern = /tmp/core.%e.%p
# /tmp ist für alle Benutzer zugänglich!

# Verwundbar: Core-Dump-Konfiguration auf Linux
# Erlaubt jedem Benutzer, Core-Dumps zu lesen
#!/bin/bash

# Verwundbar: Core-Dump-Verzeichnis auf web-zugänglichen Ort setzen
mkdir -p /var/www/html/dumps
chmod 777 /var/www/html/dumps
echo "/var/www/html/dumps/core.%e.%p" > /proc/sys/kernel/core_pattern

# Core-Dumps sind jetzt zugänglich über:
# http://example.com/dumps/core.myapp.12345

# Verwundbar: Apache stellt Verzeichnis mit Core-Dumps bereit
<VirtualHost *:80>
    DocumentRoot /var/www/html

    # Keine Einschränkung für das Bereitstellen von Core-Dump-Dateien
    # Angreifer kann zugreifen http://example.com/core.12345
</VirtualHost>

// Verwundbar: Anwendung die Core-Dumps mit Geheimnissen produzieren kann
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <signal.h>

char* db_password = NULL;
char* api_key = NULL;
char* encryption_key = NULL;

void vulnerable_process() {
    // Verwundbar: Sensible Daten im Speicher
    db_password = strdup("super_secret_db_password");
    api_key = strdup("sk_live_xxxxxxxxxxxxx");
    encryption_key = malloc(32);
    memcpy(encryption_key, "AES256-key-never-written-to-disk", 32);

    // Anwendungslogik die abstürzen könnte...
    char* null_ptr = NULL;
    *null_ptr = 'x';  // Absturz! Core-Dump enthält alle Geheimnisse!
}

int main() {
    // Verwundbar: Core-Dumps aktiviert, kein Schutz
    // signal(SIGABRT, SIG_DFL);  // Standardverhalten erstellt Core-Dump

    vulnerable_process();
    return 0;
}

# Verwundbar: Python-Anwendung mit Geheimnissen im Speicher
import os
import ctypes

# Verwundbar: Sensible Daten im Speicher zum Absturzzeitpunkt
DATABASE_URL = "postgresql://admin:[email protected]/mydb"
API_SECRET = "sk_live_abcdef123456789"
ENCRYPTION_KEY = b"32-byte-encryption-key-in-memory"

def vulnerable_function():
    # Absturz der Core-Dump produziert (auf Linux mit ulimit -c unlimited)
    ctypes.string_at(0)  # Segfault!

# Alle obigen Geheimnisse werden im Core-Dump sein

# Verwundbar: Docker-Container erlaubt Core-Dumps
FROM python:3.9

# Verwundbar: Keine Core-Dump-Einschränkungen
# Core-Dumps werden in Container-Dateisystem geschrieben

COPY app.py /app/
WORKDIR /app

# Wenn Container abstürzt, kann Core-Dump in Volume bestehen bleiben oder offengelegt werden
CMD ["python", "app.py"]

Behobene Konfiguration

# Behoben: Core-Dumps systemweit deaktivieren
# /etc/security/limits.conf
*               soft    core            0
*               hard    core            0

# Behoben: Alternativ Core-Dump-Ort und Berechtigungen einschränken
# /etc/sysctl.conf
kernel.core_pattern = |/bin/false
# Oder ein sicheres Verzeichnis verwenden:
kernel.core_pattern = /var/crash/core.%e.%p.%t
kernel.core_pipe_limit = 0

# Behoben: Core-Dump-Verzeichnis absichern
mkdir -p /var/crash
chmod 700 /var/crash
chown root:root /var/crash

# Behoben: Anwendungsebene Core-Dump-Prävention
#!/bin/bash

# Behoben: Core-Dumps für diese Sitzung deaktivieren
ulimit -c 0

# Behoben: Auch im Anwendungs-Startskript setzen
exec setrlimit --core 0 -- ./myapp

# Oder systemd-Service-Konfiguration verwenden
# [Service]
# LimitCORE=0

// Behoben: Anwendung verhindert Core-Dumps programmatisch
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/resource.h>
#include <sys/prctl.h>

void disable_core_dumps() {
    struct rlimit rl;
    rl.rlim_cur = 0;
    rl.rlim_max = 0;

    // Behoben: Core-Dumps deaktivieren
    if (setrlimit(RLIMIT_CORE, &rl) != 0) {
        perror("Fehler beim Deaktivieren von Core-Dumps");
        exit(1);
    }

    // Behoben: Auch ptrace verhindern (Speicher-Dumping)
    #ifdef PR_SET_DUMPABLE
    prctl(PR_SET_DUMPABLE, 0);
    #endif
}

// Behoben: Sensible Daten vor potenziellen Absturzpunkten löschen
void secure_cleanup(char** secret) {
    if (*secret != NULL) {
        // Behoben: Speicher vor Freigabe nullen
        volatile char* p = *secret;
        size_t len = strlen(*secret);
        while (len--) {
            *p++ = 0;
        }
        free(*secret);
        *secret = NULL;
    }
}

int main() {
    // Behoben: Core-Dumps sofort deaktivieren
    disable_core_dumps();

    char* db_password = NULL;
    char* api_key = NULL;

    // Geheimnisse verwenden...
    db_password = strdup("super_secret_db_password");
    api_key = strdup("sk_live_xxxxxxxxxxxxx");

    // Daten verarbeiten...

    // Behoben: Geheimnisse vor jeder riskanten Operation bereinigen
    secure_cleanup(&db_password);
    secure_cleanup(&api_key);

    return 0;
}

# Behoben: Python-Anwendung mit Core-Dump-Prävention
import os
import resource
import ctypes
import sys

def disable_core_dumps():
    """Core-Dump-Generierung deaktivieren."""
    try:
        # Behoben: Core-Dump-Größenlimit auf 0 setzen
        resource.setrlimit(resource.RLIMIT_CORE, (0, 0))
    except (ValueError, resource.error) as e:
        print(f"Warnung: Konnte Core-Dumps nicht deaktivieren: {e}", file=sys.stderr)

def secure_memset(data):
    """Sensible Daten sicher aus dem Speicher löschen."""
    if isinstance(data, (bytes, bytearray)):
        ctypes.memset(ctypes.addressof(
            (ctypes.c_char * len(data)).from_buffer_copy(data)
        ), 0, len(data))
    elif isinstance(data, str):
        # Hinweis: Python-Strings sind unveränderlich, dies ist best-effort
        pass

# Behoben: Core-Dumps beim Start deaktivieren
disable_core_dumps()

# Behoben: Kontextmanager für sensible Daten verwenden
from contextlib import contextmanager

@contextmanager
def secure_credential(value):
    """Kontextmanager der versucht, Anmeldedaten aus dem Speicher zu löschen."""
    cred = bytearray(value.encode() if isinstance(value, str) else value)
    try:
        yield cred
    finally:
        # Behoben: Anmeldedaten löschen
        for i in range(len(cred)):
            cred[i] = 0

# Verwendung
with secure_credential("secret_password") as password:
    # Passwort verwenden...
    pass
# Passwort-Speicher wird nach dem Block gelöscht

# Behoben: Docker-Container mit Core-Dump-Prävention
FROM python:3.9

# Behoben: Sicherheitsoptionen setzen
RUN echo "* hard core 0" >> /etc/security/limits.conf && \
    echo "* soft core 0" >> /etc/security/limits.conf

COPY app.py /app/
WORKDIR /app

# Behoben: Mit eingeschränkten Privilegien ausführen
USER nobody

# Behoben: Core-Dumps über ulimit deaktivieren
CMD ["sh", "-c", "ulimit -c 0 && exec python app.py"]

# Behoben: Kubernetes-Pod mit Core-Dump-Einschränkungen
apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    # Behoben: Privilegien-Eskalation verhindern
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      # Behoben: Alle Capabilities entziehen
      capabilities:
        drop:
          - ALL
      # Behoben: Schreibgeschütztes Dateisystem verhindert Core-Dump-Schreibvorgänge
      readOnlyRootFilesystem: true
    resources:
      limits:
        # Behoben: Kein explizites Core-Dump-Limit, aber eingeschränkte Umgebung
        memory: "128Mi"

# Behoben: Apache-Konfiguration blockiert Core-Dump-Dateien
<VirtualHost *:80>
    DocumentRoot /var/www/html

    # Behoben: Zugriff auf Core-Dump-Dateien blockieren
    <FilesMatch "^core(\.\d+)?$">
        Require all denied
    </FilesMatch>

    # Behoben: Alle core.*-Muster blockieren
    <FilesMatch "^core\..*$">
        Require all denied
    </FilesMatch>
</VirtualHost>

CVE-Beispiele

Keine spezifischen CVEs sind in der MITRE-Datenbank für dieses CWE gelistet. Das Schwachstellenmuster ist jedoch dokumentiert in:

  • CERT C Secure Coding Standard (MEM06-C)
  • Verschiedene Systemhärtungs-Richtlinien

Referenzen

  1. MITRE. "CWE-528: Exposure of Core Dump File to an Unauthorized Control Sphere." https://cwe.mitre.org/data/definitions/528.html

  2. CERT C Secure Coding Standard. "MEM06-C. Ensure that sensitive data is not written out to disk."

  3. Linux Kernel Documentation. "core(5) - core dump file."