Security-Schwachstellen in Containern erfordern runC-Patch
Gibt es Schwachstellen bei der Nutzung von Containern, müssen die Laufzeiten von runC gepatcht werden. Mehr Absicherung und Vorsicht bei merkwürdigen Container-Images ist gefragt.
Eine neu entdeckte Schwachstelle in der Containersicherheit bringt Unruhe in die Unternehmen in Schwung, da Technologien wie Docker und Kubernetes vermehrt in der Produktion zum Einsatz kommen.
Sicherheitsexperten in der Linux-Community entdeckten die Schwachstelle, die von einem Angreifer ausgenutzt werden könnte, um Root-Level-Code auf dem Container-Host zu ausführen zu können und möglicherweise den Rest einer Container-Infrastruktur für bösartige Zwecke zu kontrollieren.
Diese Art von Angriff ist theoretisch möglich, aber Red Hat-Mitarbeiter, die den Fehler bekannt gaben und den Benutzern rieten, das niedrigstufige runC-Utility zu patchen, sagten, dies sei das erste Mal, dass ein solcher Angriff tatsächlich aktiv in der Linux-Community aufgedeckt wurde. Die Experten haben zudem einen Exploit-Code veröffentlicht, der es Anbietern und Endanwendern ermöglicht, Penetrationstests in Patches für Linux-Container auf SUSE- und Red Hat Enterprise Linux-Betriebssystemen durchzuführen. Angreifer haben dann allerdings die Möglichkeit, diese Schwachstelle auszunutzen.
„Admins sehen wahrscheinlich, wie so genannte „script kiddies“ dies in anonyme Container-Images über Docker Hub einfügen. Lädt man dann ein unbekanntes Container-Image herunter, das diesen Exploit-Code enthält, könnten Unternehmen in Schwierigkeiten geraten“, sagt Scott McCarty, Principal Product Manager für Container bei Red Hat.
Best Practices für die Containersicherheit werden Realität
Das runC-Dienstprogramm ist Kern der meisten Container-Laufzeiten, so dass es einige Zeit und Planung erfordert, Patches für große Umgebungen umzusetzen und auszurollen. „Stateless“ Webanwendungen können problemlos Upgrades auf Hosts ausführen, ohne dass die Anwendungen unterbrochen werden. „Stateful“ Workloads – immer noch eine relative Seltenheit auf Containern in der Produktion – können einige Unterbrechungen erfahren, während IT-Profis Patches installieren.
Weiterhin können sich Anwender schützen, indem sie die gut dokumentierten, sinnvollen Best Practices der Containersicherheits-Community nutzen – die erste besteht darin, Container-Images nicht aus unbestätigten Internetquellen herunterzuladen und auszuführen.
„Ein Angriff würde einen böswilligen Benutzer erfordern, um einige ungewollte Dinge in das Container-Image einzubauen, und dann muss nur noch ein Benutzer diesen bösartigen Code aus Versehen herunterladen“, sagt McCarty. „Wenn Sie bereits etwas für die Containersicherheit tun, wie zum Beispiel Container-Images von einer vertrauenswürdigen Quelle ziehen (...), sind Sie wahrscheinlich immer noch ziemlich sicher.“
Das mag wie ein Kinderspiel erscheinen, aber Entwickler ohne IT-Sicherheitsexpertise oder unter Zeitdruck könnten diesen Code immer noch unwissentlich herunterladen, so Gary Chen, Analyst bei IDC.
„Im schlimmsten Fall haben Sie vielleicht auch einen bösartigen Insider“, sagt Chen.
Das runC-Dienstprogramm ist Kern der meisten Container-Laufzeiten, so dass es einige Zeit und Planung erfordert, Patches für große Umgebungen umzusetzen und auszurollen.
Sollte jemand ein solches Bild herunterladen, können viele Container-Bilderkennungsprogramme es erkennen – von Docker Bench for Security und Notar bis Cilium – obwohl dies einige Zeit dauern kann, um diese spezifische Schwachstelle zu verifizieren.
Red Hat empfiehlt Benutzern auch, SELinux-Richtlinien innerhalb des Host-Betriebssystems anzuwenden, um unbefugtes Verhalten durch kompromittierte Container zu blockieren, was diese und andere Sicherheitslücken im Container reduzieren kann, obwohl dies nicht unbedingt eine langfristige Lösung ist.
„Es ist wie ein temporärer Ersatzreifen. Es ist gut für ein paar Wochen oder Monate, während Benutzer Systeme gepatcht bekommen, aber ich möchte mich nicht ein Jahr lang darauf verlassen“, erklärt McCarty.
Die Absicherung der Containersicherheit muss Priorität haben
Dies ist nicht das schlimmste Szenario für die Containersicherheit, da diese Schwachstelle immer noch von einem IT-Experten gefunden wurde, anstatt von einem Angreifer, der diese in einer realen Umgebung nutzt. Dennoch sollte es die IT-Abteilungen von Unternehmen veranlassen, ihren Ansatz zur Absicherung der Containersicherheit auf der Netzwerkebene sowie in Hosts, Anwendungen und Container-Images gründlich zu analysieren.
Hier bieten Container-Laufzeitsicherheits-Tools wie Aqua, Twistlock und NeuVector Produkte an, die anomales Anwendungsverhalten und Netzwerkverkehr blockieren können. Das reduziert die Aktionen, die ein kompromittierter Container mit Host-Root-Zugriff in der weiteren Infrastruktur durchführen könnte. Andere Open-Source-Projekte, die reduzierte (stripped-down) VMs verwenden, um Container von Hosts zu isolieren, wie gVisor, Kata Containers und Amazon Firecracker, können ebenfalls solche potenziellen Angriffe adressieren.
Figo.io, ein Fintech-Startup in Hamburg, geht davon aus, dass ähnliche Schwachstellen wie CVE-2019-5736 auf allen Ebenen des gesamten Software-Stacks vorhanden sind und strebt einen umfassenden Schutz an, sagte Lutz Behnke, Platform Security Engineer.
„Zusätzlich zu der strengen Berechtigungsrichtlinien für jede Aufgabe verwenden wir NeuVector-Richtlinienregeln, um die Prozesse, die auf jedem Container ausgeführt werden, und die Benutzer, die sie initiieren, einzuschränken“, sagt er. „Diese Einschränkungen können Alarme auslösen oder sogar die Aktionen blockieren, je nachdem, wie essentiell der Container ist.“
Letztendlich zwingen diese RunC-Schwachstellen Unternehmen dazu, über verschiedene Ebenen der Containersicherheit nachzudenken, die sie bisher nicht hatten, fügt Chen von IDC hinzu. Als Beispiel führt er folgendes Szenario an: „Angenommen, die Containerisolierung wird zerstört. Wie werden Firmen dann damit umgehen?“
