szybnev/cve-2026-7482Reproduziert den Heap-Out-of-Bounds-Read von CVE-2026-7482 beim Laden und Quantisieren von GGUF in Ollama, mit differenzieller Analyse quantisierter Artefakte, um den Einfluss des OOB zu demonstrieren.
Dieses Repository enthält mein lokales Reproduktionsskript für CVE-2026-7482, einen Heap-Out-of-Bounds-Read in verwundbaren Ollama-GGUF-Lade- und Quantisierungspfaden.
Das wichtige Ergebnis dieser Arbeit ist eng begrenzt: Ich konnte die Heap-OOB-Bedingung zuverlässig auslösen und OOB-beeinflusste quantisierte GGUF-Artefakte erzeugen. Ich konnte keinen klaren Black-Box-Einfluss nachweisen, wie etwa eine zuverlässige Wiederherstellung von Klartext-Geheimnissen oder die direkte Extraktion von Canary-Strings aus dem resultierenden Artefakt.
exp.py erstellt zwei GGUF-Dateien:
Es lädt beide Dateien über die lokale Ollama-API auf eine verwundbare Ollama-Instanz hoch, löst eine Quantisierung mit /api/create aus, kopiert die erzeugten GGUF-Blobs aus dem lokalen Docker-Container und vergleicht die bösartige Ausgabe mit der Null-Kontroll-Ausgabe.
Der differentielle Vergleich ist nützlich, weil er zeigt, dass der verwundbare Quantisierungspfad Bytes verwendet hat, die in der ursprünglichen bösartigen GGUF-Datei nicht vorhanden waren. In meinen Tests war dieses Verhalten auf Ollama 0.17.0 stabil und wurde vom korrigierten 0.17.1-Pfad abgelehnt.
requests0.17.0, das auf einem lokalen API-Port verfügbar istollama-old-testBeispiel-Laborziel:
docker run -d --name ollama-old-test -p 11435:11434 ollama/ollama:0.17.0
Installieren Sie die einzige Python-Abhängigkeit:
python3 -m pip install requests
Führen Sie den Standardtest gegen http://localhost:11435 und Container ollama-old-test aus:
python3 exp.py
Explizite Argumente:
python3 exp.py http://localhost:11435 ollama-old-test Q4_K_M F16
python3 exp.py http://localhost:11435 ollama-old-test Q8_0 F16
python3 exp.py http://localhost:11435 ollama-old-test Q8_0 F32
Das Skript schreibt lokale Artefakte wie:
malicious_model.ggufcontrol_model.ggufquantized_model.ggufcontrol_quantized_model.ggufq8_dequantized_f32.binq8_pseudo_f16.binq8_pseudo_f16.txtIn meinen lokalen Tests erzeugte die verwundbare Ollama-Version quantisierte Ausgaben, bei denen sich die bösartige Tensor-Nutzlast von einem Null-Kontroll-Tensor unterschied, obwohl die bösartige GGUF-Datei diese Bytes nicht enthielt.
Das reicht aus, um ein OOB-beeinflusstes Artefakt zu zeigen. Es reicht nicht aus, um eine praktische Black-Box-Datenoffenlegung zu behaupten.
Ich habe auch Canary-artige Daten in gleichzeitigen Modell-Prompts getestet und die erzeugten Artefakte, Q8_0-dequantisierte Float32-Bytes und die Pseudo-F16-Rekonstruktionsausgabe durchsucht. Ich konnte weder exakte Canaries noch aussagekräftige Klartextfragmente wiederherstellen.
Der wahrscheinliche Grund ist, dass die Bytes nicht als roher Heap-Speicher kopiert werden. Sie durchlaufen die Modellkonvertierungs- und Quantisierungspipeline:
heap bytes -> als F16/F32-Tensorwerte interpretiert -> konvertiert/quantisiert -> GGUF-Tensorausgabe
Dieser Pfad ist verlustbehaftet, insbesondere bei quantisierten Formaten wie Q4_K_M. Q8_0 bewahrt mehr numerische Informationen als Q4_K_M, führte aber in meinen Black-Box-artigen Tests dennoch nicht zu einer zuverlässigen Klartextwiederherstellung.
Dies ist eine lokale Laborreproduktion und ein Hilfsmittel zur Artefaktanalyse.
Es bietet keine zuverlässige Primitive zur Remote-Geheimnisexfiltration. Es erfordert außerdem lokalen Docker-Zugriff, um den von Ollama erzeugten Blob aus dem Testcontainer zu kopieren, sodass der Analyseschritt kein reiner Remote-Black-Box-Workflow ist.
Die praktische Schlussfolgerung aus meinen Tests ist:
Es gibt auch ein separates PoC-Repository von 0x0OZ:
Diese Implementierung demonstriert einen stärkeren White-Box-artigen Workflow, indem sie das erzeugte Modellartefakt in eine kontrollierte Registry pusht. Mit dem Registry-Upload-Flow-Fix aus meinem PR läuft es in meinem lokalen Labor sauber durch:
Selbst mit diesem besseren End-to-End-Artefaktsammelpfad bleibt derselbe Datenqualitäts-Vorbehalt wichtig: Die Ausgabe sind quantisierte/modelltransformierte Daten, kein direkter roher Heap-Dump.
Dieses Repository dient ausschließlich autorisierter Schwachstellenforschung und defensiver Reproduktion. Testen Sie nur gegen Systeme, die Sie besitzen oder für deren Bewertung Sie eine ausdrückliche Genehmigung haben.