Auswirkungen
CVE-2024-21626 kann es einem bösartigen Image oder einem an der Containerausführung beteiligten Prozess ermöglichen, einem betroffenen runc-Container zu entkommen und auf das Host-Dateisystem zuzugreifen. Von den runc-Betreuern dokumentierte Varianten können auch Host-Binärdateien überschreiben und zu einer vollständigen Host-Kompromittierung von [S1] führen. NVD zeichnet das gleiche Container-Breakout-Verhalten und den runc 1.1.12 Fix [S2] auf.
Grundursache und betroffene Versionen
Die Upstream-Beratung deckt die runc-Versionen von 1.0.0-rc93 bis 1.1.11 ab. Interne Dateideskriptoren könnten für den Containerprozess verfügbar bleiben und in den betroffenen Versionen wurde nicht überprüft, ob das endgültige Arbeitsverzeichnis im Container-Mount-Namespace [S1] verbleibt. Ein schädliches Container-Arbeitsverzeichnis wie „/proc/self/fd/7“ könnte daher in den Host-Namespace aufgelöst werden. runc 1.1.12 schließt die durchgesickerten Deskriptoren und validiert das Arbeitsverzeichnis vor der Ausführung von [S1].
Abgedeckt von FixVibe
Verbundene GitHub-Repo-Scans kennzeichnen jetzt die Workload-Konfiguration Dockerfile und Kubernetes, die mit dieser Container-Breakout-Bedingung verknüpft ist. Die Ergebnisse identifizieren die betroffene Repository-Datei und den Speicherort der Konfiguration, verwenden einen Beweisstatus Wahrscheinliches Problem und geben an, dass die Konfidenz für die Quelle/Konfigurationsübereinstimmung gilt.
FixVibe führt keine Images oder Container aus, greift nicht auf Hostdateien zu, überschreibt Binärdateien und versucht keinen Ausbruch. Ein Repo-Ergebnis beweist nicht, dass die Konfiguration bereitgestellt ist, dass der Host runc verwendet oder dass die bereitgestellte Laufzeit in den betroffenen Versionsbereich fällt. Kunden sollten den tatsächlichen Laufzeitbestand überprüfen, bevor sie den Befund als bestätigte Live-Ausnutzung behandeln.
Sanierung
Ersetzen Sie das Container-Arbeitsverzeichnis durch einen normalen Pfad innerhalb des Images. Führen Sie ein Upgrade aller Docker-, containerd-, Erstellen Sie überprüfte Bilder und Manifeste neu und stellen Sie sie erneut bereit, damit veraltete Artefakte die riskante Konfiguration nicht beibehalten können.
Da dieser Arbeitsverzeichniszustand höchst ungewöhnlich ist, überprüfen Sie den einleitenden Commit, die Image-Herkunft, die Registrierungssignaturen, die Zulassungs- und Überwachungsprotokolle sowie die Containeraktivität. Eskalieren Sie über den Incident-Response-Prozess des Eigentümers, wenn die Konfiguration eine ausführbare Umgebung erreicht.