Fork Bombs sind keine neue Sache, aber offenbar in der Lage, ein Kubernetes aus den Angeln zu heben. Wie sich die Bombe entschärfen lässt und welche weiteren potenziellen Probleme in Build-Umgebungen lauern, war Thema auf der Black Hat Europe.

In ihrem Vortrag legten Etienne Stalmans, Chris Le Roy und Matthias Luft, die bei Heroku im Security-Bereich arbeiten, ihren Fokus auf die Sicherheit von Build-Umgebungen. Vor allem in mandantenfähigen Cloud-Umgebungen teilen sich die Mandanten mitunter die Buildumgebungen für Container. In diesem Fall lauern dann aber gleich mehrerer Einfallstore für Angriffe (zu den Folien vom Vortrag).

Dockerfiles und die darin enthaltenen Befehle dienen als Grundlage zum Bau von Containern. Der Buildprozess erzeugt dabei für jeden Schritt im Dockerfile ein eigenes Intermediate Image, eine Layer. Ein Docker-Image besteht dann aus einer Kombination von nur-lesbaren Layern, die eine eigene ID erhalten. Allerdings, und das ist das Problem, gibt es Wege, das Dockerfile zu manipulieren, um den Buildprozess für Angriffe zu nutzen.

Rollkommandos

So lässt sich etwa über das “ADD”-Kommando auf Ressourcen des Host zugreifen, wozu zum Beispiel Zertifikate und Schlüssel zählen. Über “ARG” lassen sich Build-Variablen vom Build-Host auslesen, die potenziell sensible Daten enthalten, etwa Hostnamen, IP-Adressen oder Benutzernamen. Spezifiziert der “FROM”-Befehl die gewollten Images ungenau, lassen sich ihm über den Cache andere Images unterschieben.

Auch alte Probleme kehren im neuen Gewand zurück. Über das Dockerfile lassen sich zum Beispiel klassische Fork-Bomben erzeugen, die nicht weiter tun, als durch rekursive Kopien die Ressourcen des Systems zu erschöpfen. Laut den Vortragenden gelang es damit nicht nur, eine Container-Runtime zum Absturz zu bringen, sondern gleich einen kompletten Kubernetes-Cluster.

Gegensteuern

Das klingt unschön, doch es gibt auch Maßnahmen, solche Angriffe zu unterbinden. Die Standards für die Container-Runtimes geben oft keine Limits für die Ressourcen-Nutzung vor. Diese lassen sich aber einstellen, was den Einsatz von Forkbomben erschwert. Auch auf dem Container-Level lassen sich für die Ressourcen-Nutzung Obergrenzen konfigurieren. Nicht zuletzt empfehlen Stalmans, Le Roy und Luft, in mandantenfähigen Umgebungen, in denen die Kontrolle über den Buildprozess fehlt, dedizierte VMs, Kubernetes-Cluster und Docker-Instanzen zu verwenden und zudem Zeitlimits für Builds einzusetzen.

Buildsicherheit

Nicht zuletzt zeigte der Vortrag, dass auch die Komponenten einer Build-Umgebung zu kapern sind. So sendet der Build-Orchestrator mitunter ein “Poweroff” an den Build-Container, sobald der seinen Job erledigt hat. Gelingt es, das Signal abzufangen, erhält der Angreifer kostenlose Compute-Zeit. Auch Tokens lassen sich abfangen. Das ist etwa der Fall, wenn die Buildumgebung fertige Builds in einen S3-Bucket schieben möchte und dabei auch den S3-Token überträgt.

Nicht zuletzt können bösartige Docker-Images Probleme verursachen. Hier besteht eine Lösung darin, die Container zu signieren. Mit Terrier will Heroku demnächst zudem ein Open-Source-Tool anbieten, um die Docker-Image-Komponenten vor dem Buildprozess zu verifizieren.