Sicherheitsforscher brechen aus Docker-Container aus
Forschern ist es gelungen, aus einem Container der Docker-Testumgebung "Play with Docker" auf das darunterliegende System zuzugreifen und Code auszufĂĽhren.
Forschern gelang es, aus dem Experimentiercontainer von Play with Docker auszubrechen. Das Vorgehen zeigt, dass die Isolierung von Prozessen in Containern allein keine vollständige Sicherheit bietet.
- Jan Mahn
Die Docker-Spielwiese Play with Docker erlaubt kostenlose Experimente mit Docker-Containern in einer Weboberfläche. Jeder Benutzer bekommt einen Container mit Alpine-Linux, in dem er wiederum seine Test-Container starten darf (Docker in Docker). Sicherheitsforschern des Unternehmens CyberArk ist es Ende 2018 gelungen, aus dieser Container-Umgebung auszubrechen und Code auf der darunterliegenden Maschine auszuführen. Die konkrete Sicherheitslücke in Play with Docker wurde jetzt geschlossen, der Fall zeigt aber einmal mehr, dass Container-Technik keine komplette Abschottung leistet.
Ein Container enthält nur das Userland einer Linux-Distribution und das auszuführende Programm. Der Kernel wird im Container nicht erneut geladen – stattdessen nutzen alle Container den Kernel des darunterliegenden Betriebssystems. Den CyberArk-Forschern gelang es, dem Kernel ein eigenes Modul unterzuschieben und darüber eine Shell auf dem Gastgebersystem zu starten. Ihren Ausbruch beschreiben sie in einem detaillierten Blog-Beitrag.
Expedition mit Standard-Linux-Werkzeug
Zunächst verschafften die Forscher sich mit uname -a einen Überblick über ihren Gastgeber, versuchten das darunterliegende Dateisystem zu mounten und scheiterten an einem Sicherheitsmechanismus. Erfolgreicher war eine Analyse mit dem Debugger von debugfs. Lesend bewegten sie sich auf dem Dateisystem des Betriebssystems.
Um ihr Ziel zu erreichen, eigenen Code auszuführen, suchten sie nach einem Modul, das die Kernel-Funktion printk verwendet und darüber bereitwillig Informationen zum Kernel preisgibt. Sie fanden das Modul ceph.ko für die Ceph-Unterstützung und sammelten die benötigten Details zum Kernel. Ihr Ziel: Ein eigenes Modul zu kompilieren, das zumindest vorgibt, auf exakt der gleichen Kernelversion kompiliert worden zu sein. Nur so lässt der Kernel die Ausführung überhaupt zu.
Eigenes Modul fĂĽr den Kernel
Der Einsatz war erfolgreich. Die Forscher bauten ein eigenes Modul, schoben ihm die ermittelten Informationen zum verwendeten Kernel unter und lieĂźen den Gastgeber das Modul ausfĂĽhren. Dieses startete eine Busybox-Shell, die Zugriff auf das Betriebssystem erlaubte. Aus dem Container konnten sie den Host bedienen.
Als "schwierig – aber nicht unmöglich" beschreiben Eviatar Gerzi und sein Team von CyberArk den erfolgreichen Ausbruch und fassen das Problem zusammen: Play with Docker ließ den Container mit erhöhten Rechten laufen. Nur so war die Ausführung des eigenen Kernel-Moduls überhaupt möglich. Im November informierten die Forscher Play With Docker, Anfang Januar war das Problem beseitigt.
Für die Nutzer von Play with Docker sollte der Angriff keine unangenehmen Folgen gehabt haben – in der Spielwiese sollten ohnehin weder wertvolle Daten liegen noch produktive Systeme laufen. Die Plattform dient vor allem zu Demo-Zwecken und ist bei Entwicklerkonferenzen für Präsentationen und Schulungen im Einsatz. Abgesehen von der konkreten und geschlossenen Lücke bei Play with Docker führt der Fall für Betreibern von Cloud-Infrastruktur vor Augen, dass Container ohne weitere Sicherungsmaßnahmen keine hundertprozentige Isolierung von Kundenprozessen im Container und Gastgeber-Betriebssystem bieten. (jam)
