Zurück zur Schwachstellen-Datenbank

Unkontrollierter Ressourcenverbrauch

Beschreibung

Unkontrollierter Ressourcenverbrauch tritt auf, wenn ein Produkt die Zuweisung und Wartung begrenzter Ressourcen nicht ordnungsgemäß kontrolliert, was einem Angreifer ermöglicht, die Menge der verbrauchten Ressourcen zu beeinflussen und sie potenziell zu erschöpfen. Begrenzte Ressourcen umfassen Arbeitsspeicher, CPU-Zyklen, Dateideskriptoren, Netzwerkverbindungen, Festplattenspeicher und Datenbankverbindungen. Wenn Angreifer unbegrenzte Ressourcenzuweisung ohne ordnungsgemäße Kontrollen auslösen können, können sie Denial-of-Service verursachen, indem sie verfügbare Ressourcen erschöpfen und legitimen Benutzern den Zugang zum System verwehren.

Risiko

Ressourcenverbrauchsangriffe gehören zu den häufigsten Denial-of-Service-Vektoren. Angreifer benötigen minimale Ressourcen, um massiven Verbrauch auf dem Ziel auszulösen. "Slowloris"-Angriffe erschöpfen Webserver-Verbindungen mit langsamen Anfragen. Algorithmische Komplexitätsangriffe nutzen ineffiziente Operationen aus, um CPU zu verbrauchen. Speichererschöpfungsangriffe allozieren Speicher schneller als er freigegeben werden kann. Aktuelle Schwachstellen in industriellen Steuerungssystemen (EFACEC), Druckdiensten (CUPS) und Netzwerkausrüstung (Arista) zeigen, dass diese Schwäche kritische Infrastruktur betrifft. Ressourcenerschöpfung kann kaskadieren und abhängige Dienste sowie ganze Systeme zum Absturz bringen.

Lösung

Implementieren Sie strikte Limits für Ressourcenzuweisung pro Benutzer, Sitzung und Anfrage. Verwenden Sie Timeouts für alle Operationen, die Ressourcen verbrauchen. Implementieren Sie Rate-Limiting, um schnelle Ressourcenzuweisung zu verhindern. Setzen Sie Verbindungslimits, Anfragegrößenlimits und Abfragekomplexitätslimits. Verwenden Sie Ressourcenpools mit festen Maximalgrößen. Überwachen Sie den Ressourcenverbrauch und implementieren Sie Alarme. Wenden Sie Eingabevalidierung an, um algorithmische Komplexitätsangriffe zu verhindern. Konfigurieren Sie Systeme so, dass sie bei Ressourcenerschöpfung graceful versagen, anstatt abzustürzen.

Häufige Auswirkungen

AuswirkungDetails
VerfügbarkeitUmfang: Denial of Service

Ressourcenerschöpfung verhindert, dass legitime Benutzer auf Dienste zugreifen können, was Systemunverfügbarkeit verursacht.
SystemstabilitätUmfang: Systemabsturz

Unkontrollierter Ressourcenverbrauch kann Prozesse oder ganze Systeme zum Absturz bringen.
FinanziellUmfang: Ressourcenkosten

In Cloud-Umgebungen können Ressourcenerschöpfungsangriffe erhebliche Rechenkosten verursachen.

Beispielcode

Anfälliger Code

# ANFÄLLIG: Kein Limit für Datei-Upload-Größe
@app.route('/upload', methods=['POST'])
def upload():
    # Angreifer kann riesige Dateien hochladen und Festplatte füllen
    file = request.files['file']
    file.save(f'/uploads/{file.filename}')
    return 'OK'

# ANFÄLLIG: Kein Timeout für externe Anfragen
def fetch_url(url):
    # Langsamer Server kann Verbindung unbegrenzt blockieren
    response = requests.get(url)  # Kein Timeout!
    return response.text

# ANFÄLLIG: Unbegrenzte Liste im Speicher
def process_items(item_ids):
    # Angreifer sendet Millionen von IDs
    results = []
    for id in item_ids:  # Kein Limit für item_ids Länge
        results.append(fetch_item(id))
    return results

// ANFÄLLIG: Unbegrenzter Regex verursacht ReDoS
public boolean validateEmail(String email) {
    // Böser Regex - exponentielles Backtracking
    return email.matches("^([a-z]+)+@[a-z]+\\.[a-z]+$");
}

// ANFÄLLIG: Kein Verbindungslimit
ServerSocket server = new ServerSocket(8080);
while (true) {
    // Jede Verbindung nutzt einen Thread - kann Threads erschöpfen
    Socket client = server.accept();
    new Thread(() -> handleClient(client)).start();
}

Korrigierter Code

from flask import Flask, request
import requests
from functools import wraps
import time

# SICHER: Upload-Größe begrenzen
app = Flask(__name__)
app.config['MAX_CONTENT_LENGTH'] = 16 * 1024 * 1024  # 16 MB Limit

@app.route('/upload', methods=['POST'])
def upload_safe():
    file = request.files['file']

    # Zusätzliche Validierung
    if file.content_length > app.config['MAX_CONTENT_LENGTH']:
        return 'Datei zu groß', 413

    file.save(f'/uploads/{secure_filename(file.filename)}')
    return 'OK'

# SICHER: Timeout für alle externen Anfragen
def fetch_url_safe(url):
    try:
        response = requests.get(url, timeout=10)  # 10 Sekunden Timeout
        return response.text
    except requests.Timeout:
        return None

# SICHER: Limit für Batch-Verarbeitung
MAX_BATCH_SIZE = 100

def process_items_safe(item_ids):
    # Anzahl der verarbeiteten Elemente begrenzen
    if len(item_ids) > MAX_BATCH_SIZE:
        raise ValueError(f"Batch-Größe überschreitet Limit von {MAX_BATCH_SIZE}")

    results = []
    for id in item_ids:
        results.append(fetch_item(id))
    return results

# SICHER: Rate-Limiting-Dekorator
def rate_limit(max_per_minute):
    def decorator(f):
        calls = []
        @wraps(f)
        def wrapper(*args, **kwargs):
            now = time.time()
            calls[:] = [c for c in calls if c > now - 60]
            if len(calls) >= max_per_minute:
                raise RateLimitExceeded()
            calls.append(now)
            return f(*args, **kwargs)
        return wrapper
    return decorator

@rate_limit(max_per_minute=60)
def api_endpoint():
    return process_request()

// SICHER: Linearer Regex ohne Backtracking
public boolean validateEmailSafe(String email) {
    // Einfacher Regex ohne katastrophales Backtracking
    return email.matches("^[a-z]+@[a-z]+\\.[a-z]+$");
}

// SICHER: Thread-Pool mit fester Größe
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

ExecutorService executor = Executors.newFixedThreadPool(100);  // Max 100 Threads

ServerSocket server = new ServerSocket(8080);
while (true) {
    Socket client = server.accept();
    executor.submit(() -> {
        try {
            handleClient(client);
        } finally {
            client.close();
        }
    });
}

Ausgenutzt in der Praxis

EFACEC QC Industriesysteme (EFACEC, 2026)

CVE-2026-22542 betrifft EFACEC QC 60/90/120 Industriesysteme, bei denen bereits zwei gleichzeitige Telnet-Verbindungen Ressourcen erschöpfen und mit minimalem Aufwand Denial-of-Service verursachen.

OpenPrinting CUPS Slowloris (CUPS, 2025)

CVE-2025-58436 ermöglicht es Angreifern, DoS gegen CUPS-Druckdienste zu verursachen, indem sie Daten mit einem Byte pro Sekunde senden und den cupsd-Daemon aufgrund fehlender Timeout-Behandlung blockieren.

HTTP/2 Rapid Reset Angriff (Mehrere, 2023)

CVE-2023-44487 nutzte den Stream-Reset-Mechanismus von HTTP/2 aus, um massive Anfragezahlen zu generieren und Server zu überlasten. Dies betraf nahezu alle HTTP/2-Implementierungen weltweit.

Tools zum Testen/Ausnutzen

  • slowloris — Langsames HTTP-DoS-Testtool.

  • wrk — HTTP-Benchmarking für Lasttests.

  • ReDoS Checker — Regex auf katastrophales Backtracking testen.

CVE-Beispiele

Referenzen

  1. MITRE. "CWE-400: Uncontrolled Resource Consumption." https://cwe.mitre.org/data/definitions/400.html

  2. OWASP. "Denial of Service." https://owasp.org/www-community/attacks/Denial_of_Service