Exposure of Core Dump File to an Unauthorized Control Sphere

Description

Exposure of Core Dump File to an Unauthorized Control Sphere is a vulnerability where a product generates core dump files in a directory, archive, or other resource that is accessible to unauthorized actors. Core dumps are memory snapshots created when a program crashes, containing the complete process memory state at the time of failure. These files may contain sensitive information such as encryption keys, passwords, personal data, database contents, and application secrets that were present in memory at the time of the crash.

Risk

Core dump files present significant confidentiality risks because they contain raw memory contents. Passwords and authentication tokens that were never written to disk may be recoverable from core dumps. Encryption keys used for data protection become exposed. Personal user data being processed at the time of the crash is captured. Database query results and connection strings may be present. The risk is amplified when core dumps are written to world-readable directories, stored in accessible locations on web servers, or included in error reports sent to third parties. Attackers who gain access to core dumps can extract credentials and secrets without ever compromising the running application.

Solution

Configure systems to prevent core dump generation in production environments where possible, or restrict core dump file permissions and storage locations. Use secure directories with appropriate access controls for core dump storage. Disable core dumps for processes handling sensitive data. When core dumps are needed for debugging, ensure they are written to protected directories not accessible via web servers or other public interfaces. Implement automatic cleanup of core dump files. Consider using sanitized crash dumps that exclude sensitive memory regions. Apply the principle of least privilege to core dump file access.

Common Consequences

Impact	Details
Confidentiality	Scope: Confidentiality Read Application Data - Core dumps contain the complete memory state of the process, potentially including passwords, encryption keys, personal data, and other sensitive information.
Confidentiality	Scope: Confidentiality Read Files or Directories - Attackers accessing core dumps can read data that was never intended to be written to disk, including in-memory caches and temporary data.

Example Code

Vulnerable Configuration

# Vulnerable: Core dumps enabled with permissive settings
# /etc/security/limits.conf
*               soft    core            unlimited
*               hard    core            unlimited

# Vulnerable: Core dumps written to world-readable directory
# /etc/sysctl.conf
kernel.core_pattern = /tmp/core.%e.%p
# /tmp is accessible by all users!

# Vulnerable: Core dump configuration on Linux
# Allows any user to read core dumps
#!/bin/bash

# Vulnerable: Setting core dump directory to web-accessible location
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 are now accessible via:
# http://example.com/dumps/core.myapp.12345

# Vulnerable: Apache serving directory containing core dumps
<VirtualHost *:80>
    DocumentRoot /var/www/html

    # No restriction on serving core dump files
    # Attacker can access http://example.com/core.12345
</VirtualHost>

// Vulnerable: Application that may produce core dumps with secrets
#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() {
    // Vulnerable: Sensitive data in memory
    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);

    // Application logic that might crash...
    char* null_ptr = NULL;
    *null_ptr = 'x';  // Crash! Core dump contains all secrets!
}

int main() {
    // Vulnerable: Core dumps enabled, no protection
    // signal(SIGABRT, SIG_DFL);  // Default behavior creates core dump

    vulnerable_process();
    return 0;
}

# Vulnerable: Python application with secrets in memory
import os
import ctypes

# Vulnerable: Sensitive data in memory at crash time
DATABASE_URL = "postgresql://admin:[email protected]/mydb"
API_SECRET = "sk_live_abcdef123456789"
ENCRYPTION_KEY = b"32-byte-encryption-key-in-memory"

def vulnerable_function():
    # Crash that produces core dump (on Linux with ulimit -c unlimited)
    ctypes.string_at(0)  # Segfault!

# All secrets above will be in the core dump

# Vulnerable: Docker container allowing core dumps
FROM python:3.9

# Vulnerable: No core dump restrictions
# Core dumps will be written to container filesystem

COPY app.py /app/
WORKDIR /app

# If container crashes, core dump may persist in volume or be exposed
CMD ["python", "app.py"]

Fixed Configuration

# Fixed: Disable core dumps system-wide
# /etc/security/limits.conf
*               soft    core            0
*               hard    core            0

# Fixed: Alternatively, restrict core dump location and permissions
# /etc/sysctl.conf
kernel.core_pattern = |/bin/false
# Or use a secure directory:
kernel.core_pattern = /var/crash/core.%e.%p.%t
kernel.core_pipe_limit = 0

# Fixed: Secure the core dump directory
mkdir -p /var/crash
chmod 700 /var/crash
chown root:root /var/crash

# Fixed: Application-level core dump prevention
#!/bin/bash

# Fixed: Disable core dumps for this session
ulimit -c 0

# Fixed: Also set in application startup script
exec setrlimit --core 0 -- ./myapp

# Or use systemd service configuration
# [Service]
# LimitCORE=0

// Fixed: Application preventing core dumps programmatically
#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;

    // Fixed: Disable core dumps
    if (setrlimit(RLIMIT_CORE, &rl) != 0) {
        perror("Failed to disable core dumps");
        exit(1);
    }

    // Fixed: Also prevent ptrace (memory dumping)
    #ifdef PR_SET_DUMPABLE
    prctl(PR_SET_DUMPABLE, 0);
    #endif
}

// Fixed: Clear sensitive data before potential crash points
void secure_cleanup(char** secret) {
    if (*secret != NULL) {
        // Fixed: Zero out memory before freeing
        volatile char* p = *secret;
        size_t len = strlen(*secret);
        while (len--) {
            *p++ = 0;
        }
        free(*secret);
        *secret = NULL;
    }
}

int main() {
    // Fixed: Disable core dumps immediately
    disable_core_dumps();

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

    // Use secrets...
    db_password = strdup("super_secret_db_password");
    api_key = strdup("sk_live_xxxxxxxxxxxxx");

    // Process data...

    // Fixed: Clean up secrets before any risky operation
    secure_cleanup(&db_password);
    secure_cleanup(&api_key);

    return 0;
}

# Fixed: Python application with core dump prevention
import os
import resource
import ctypes
import sys

def disable_core_dumps():
    """Disable core dump generation."""
    try:
        # Fixed: Set core dump size limit to 0
        resource.setrlimit(resource.RLIMIT_CORE, (0, 0))
    except (ValueError, resource.error) as e:
        print(f"Warning: Could not disable core dumps: {e}", file=sys.stderr)

def secure_memset(data):
    """Securely clear sensitive data from memory."""
    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):
        # Note: Python strings are immutable, this is best-effort
        pass

# Fixed: Disable core dumps at startup
disable_core_dumps()

# Fixed: Use context manager for sensitive data
from contextlib import contextmanager

@contextmanager
def secure_credential(value):
    """Context manager that attempts to clear credential from memory."""
    cred = bytearray(value.encode() if isinstance(value, str) else value)
    try:
        yield cred
    finally:
        # Fixed: Clear the credential
        for i in range(len(cred)):
            cred[i] = 0

# Usage
with secure_credential("secret_password") as password:
    # Use password...
    pass
# Password memory is cleared after the block

# Fixed: Docker container with core dump prevention
FROM python:3.9

# Fixed: Set security options
RUN echo "* hard core 0" >> /etc/security/limits.conf && \
    echo "* soft core 0" >> /etc/security/limits.conf

COPY app.py /app/
WORKDIR /app

# Fixed: Run with restricted privileges
USER nobody

# Fixed: Disable core dumps via ulimit
CMD ["sh", "-c", "ulimit -c 0 && exec python app.py"]

# Fixed: Kubernetes pod with core dump restrictions
apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    # Fixed: Prevent privilege escalation
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      # Fixed: Drop all capabilities
      capabilities:
        drop:
          - ALL
      # Fixed: Read-only filesystem prevents core dump writes
      readOnlyRootFilesystem: true
    resources:
      limits:
        # Fixed: No explicit core dump limit, but restricted environment
        memory: "128Mi"

# Fixed: Apache configuration blocking core dump files
<VirtualHost *:80>
    DocumentRoot /var/www/html

    # Fixed: Block access to core dump files
    <FilesMatch "^core(\.\d+)?$">
        Require all denied
    </FilesMatch>

    # Fixed: Block all core.* patterns
    <FilesMatch "^core\..*$">
        Require all denied
    </FilesMatch>
</VirtualHost>

---

CVE Examples

No specific CVEs are listed in the MITRE database for this CWE. However, the vulnerability pattern is documented in:

• CERT C Secure Coding Standard (MEM06-C)
• Various system hardening guidelines

---

References

1. MITRE Corporation. "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."