Der geteilte Kernel ist die Lücke: Warum Copy Fail aus dem Container ausbricht
8 Min. Lesezeit
Container fühlen sich an wie abgeschottete Räume, doch sie teilen sich alle denselben Kernel des Hosts. Genau diese geteilte Schicht ist die eigentliche Grenze der Isolation, und sie hält nicht, wenn im Kernel selbst ein Fehler steckt. Die jüngst offengelegte Lücke Copy Fail führt das vor: ein Fehler, der seit fast einem Jahrzehnt im Code schlummerte und aus einem einzigen kompromittierten Container den ganzen darunterliegenden Knoten öffnet.
Das Wichtigste in Kürze
- Container sind keine Kernel-Grenze. Alle Container eines Hosts teilen sich dessen Kernel. Ein Kernel-Fehler hebelt die scheinbare Trennung aus.
- Alte Fehler bleiben gefährlich. Copy Fail steckte seit Kernel 4.14 im Code. Alter schützt nicht, ein öffentlicher Exploit macht die Lücke sofort relevant.
- Verteidigung braucht mehrere Schichten. Patch-Disziplin, eingeschränkte Syscalls und harte Knoten-Trennung wiegen schwerer als das Vertrauen in die Container-Grenze allein.
Verwandt:Linux-Kernel-Lücken: BSI warnt vor Root-Eskalation / Warum dieselbe Lücken-Klasse immer wiederkommt
Die geteilte Schicht, die niemand sieht
Ein Container kapselt Prozesse, Dateisysteme und Netzwerk, aber er bringt keinen eigenen Kernel mit. Anders als eine virtuelle Maschine läuft er direkt auf dem Kernel des Hosts und teilt ihn mit allen anderen Containern auf derselben Maschine. Diese gemeinsame Schicht ist der Grund für die Leichtigkeit von Containern, und zugleich ihre verwundbarste Stelle. Wer den Kernel kompromittiert, steht nicht mehr in einem Container, sondern auf dem Host.
Copy Fail nutzt genau diesen Umstand. Der Linux-Kernel verwaltet einen global geteilten Page-Cache, der über Container-Grenzen hinweg gilt, ohne eigene Namespace-Trennung. Ein unprivilegierter Prozess in einem Container kann über die Lücke wenige kontrollierte Bytes in den Cache einer für ihn lesbaren Datei schreiben und sich darüber Root-Rechte verschaffen. Weil der Cache geteilt ist, reicht der Schreibzugriff bis auf den Host und in andere Container hinein.
Was ist ein Container-Escape? Ein Container-Escape ist der Ausbruch eines Angreifers aus der Isolation eines Containers auf den darunterliegenden Host oder in benachbarte Container. Möglich wird er meist über den gemeinsam genutzten Kernel: Wer dort eine Schwachstelle ausnutzt, umgeht die Trennung, die der Container zu garantieren scheint.
Warum das Alter der Lücke keine Entwarnung ist
Copy Fail ist kein frischer Programmierfehler, sondern war seit Kernel 4.14 vorhanden, also seit rund neun Jahren. Das ist kein Einzelfall, sondern ein Muster: Fehlerklassen überleben lange im Code, weil niemand gezielt nach ihnen sucht, bis jemand es doch tut. Der entscheidende Wandel ist nicht das Alter, sondern der Moment der Veröffentlichung. Sobald ein funktionierender Exploit kursiert, sinkt die nötige Angreiferkompetenz schlagartig.
Für Betreiber von Container-Plattformen verschiebt das die Dringlichkeit. Eine Lücke, die jahrelang theoretisch war, wird mit dem veröffentlichten Code zur akuten Gefahr. Das gilt besonders für Umgebungen mit gemischter Last, in denen wenig vertrauenswürdiger Code neben sensiblen Diensten auf demselben Knoten läuft. Dort ist der Container-Escape kein abstraktes Risiko, sondern der direkte Weg vom unwichtigen Workload zum kompletten Knoten.
Was wirklich schützt
Die wichtigste Einsicht ist konzeptionell: Der Container ist eine Betriebsgrenze, keine harte Sicherheitsgrenze gegen Kernel-Fehler. Wer das akzeptiert, baut Verteidigung in Schichten statt auf eine einzelne Annahme. Patch-Disziplin steht dabei an erster Stelle, denn gegen eine bekannte Lücke mit öffentlichem Exploit hilft vor allem der eingespielte Fix.
Falsche Sicherheit
- Der Container gilt als harte Grenze
- Wenig vertrauenswürdige Last neben sensiblen Diensten
- Kernel-Patches gelten als unkritisch
Mehrschichtige Abwehr
- Kernel-Patches zeitnah und priorisiert einspielen
- Syscalls per seccomp eng begrenzen
- Sensible Workloads auf eigene Knoten trennen
Hinzu kommt die Einschränkung dessen, was ein Container überhaupt tun darf. Ein eng gesetztes Syscall-Profil nimmt vielen Kernel-Exploits die Grundlage, weil sie den verwundbaren Pfad gar nicht erst erreichen. Und wo Workloads mit unterschiedlichem Vertrauensniveau zusammenkommen, gehört die harte Trennung auf eigene Knoten dazu, damit ein Ausbruch nicht gleich die sensiblen Nachbarn mitnimmt. Keine dieser Maßnahmen ist neu, aber Copy Fail führt vor, warum sie zusammen gehören.
Häufige Fragen
Sind Container weniger sicher als virtuelle Maschinen?
Sie isolieren anders. Eine virtuelle Maschine bringt einen eigenen Kernel mit, Container teilen den des Hosts. Gegen Kernel-Fehler bietet die VM daher eine stärkere Grenze. Dafür sind Container leichter und schneller. Die richtige Wahl hängt vom Vertrauensniveau der Workloads ab.
Hilft ein aktuelles Container-Image gegen Copy Fail?
Nein, denn die Lücke sitzt im Kernel des Hosts, nicht im Image. Entscheidend ist, dass der Host-Kernel gepatcht wird. Ein noch so aktuelles Image schützt nicht, wenn der darunterliegende Kernel verwundbar bleibt.
Was bringt seccomp gegen Kernel-Exploits?
Ein seccomp-Profil schränkt ein, welche Systemaufrufe ein Container nutzen darf. Viele Kernel-Exploits brauchen bestimmte Syscalls, um den verwundbaren Pfad zu erreichen. Sind diese gesperrt, läuft der Angriff ins Leere, auch wenn die Lücke selbst noch besteht.
Warum fallen solche Fehler erst nach Jahren auf?
Weil gezielte Suche selten ist. Fehlerklassen überleben lange unbemerkt, bis ein Forscher genau hinschaut. Das Alter sagt nichts über die Gefahr aus. Erst der veröffentlichte Exploit verwandelt eine theoretische Lücke in ein akutes Risiko.
Welche Umgebungen sind besonders gefährdet?
Solche mit gemischter Last, in denen wenig vertrauenswürdiger Code neben sensiblen Diensten auf demselben Knoten läuft. Dort ist der Weg vom unwichtigen Workload zum kompletten Knoten kurz. Die Trennung sensibler Lasten auf eigene Knoten senkt dieses Risiko deutlich.
Mehr aus dem MBF Media Netzwerk
Quelle Titelbild: Pexels / panumas nikhomkhai (px:17489157)
