On-entry container attack - CVE-2016-9962

Eine Container On-Entry-Schwachstelle wurde in Docker entdeckt, die unter CVE-2016-9962 geführt wird. Die Schwachstelle betrifft einen speziellen Angriff, der ptrace und inkorrekt bereinigte Dateideskriptoren verwendet, um Zugriff auf Inhalte außerhalb eines Containers zu erlangen. Dieser Angriff stellt nur dann ein Risiko dar, wenn privilegierte Container ausgeführt werden, und kann mithilfe von SELinux vollständig vermieden werden.

Dieses Problem wurde am 10. Januar 2017 öffentlich bekannt gemacht.

Hintergrundinformationen

Diese Schwachstelle tritt auf, wenn ein Prozess, der normalerweise in einem Namensraum ausgeführt wird, in einen anderen Namensraum verlegt oder darin gestartet wird. Namensräume agieren in der Regel als Sicherheitsmechanismus, da Prozesse innerhalb verschiedener Namensräume sich nicht gegenseitig sehen oder manipulieren können. Das Problem tritt auf, weil beim Verlegen eines Prozesses in einen anderen Namensraum dieser Prozess anfällig ist für bösartige Angriffe von Prozessen, die sich bereits in diesem Namensraum befinden. On-Entry-Schwachstellen greifen Prozesse an, die mittels nsenter oder docker exec in Container einsteigen. Ein erfolgreicher Angriff kann dazu führen, dass ein bösartiger Prozess Systemzugriff oder andere Privilegien erlangt.

Falls beispielsweise ein bösartiger Prozess einen Container übernommen hat und es geschafft hat, root- Rechte innerhalb dieses Containers zu erlangen, so kann der bösartige Prozess jeden anderen für ihn „sichtbaren“ Prozess beenden. Glücklicherweise hindern Container-Namensräume den bösartigen Prozess daran, Prozesse auf dem Host oder in anderen Containern zu finden und zu beenden. Wenn allerdings ein Administrator das Problem zu diagnostizieren versucht, indem er mithilfe von nsenter eine Shell in den infizierten Container einführt, so kann der bösartige Prozess diese Shell ebenfalls entdecken, manipulieren und ggf. beenden.

Anfällige Linux-Dienstprogramme

Die folgenden legitimen Linux-Dienstprogramme können für On-Entry-Angriffe missbraucht werden. Verwenden Sie Linux-Sicherheitsmechanismen wie z. B. SELinux und seccomp, um das Ausnutzen dieser Schwachstelle zu verhindern.

• ptrace
  „Process trace“ oder ptrace ist ein leistungsstarkes Debugging-Tool in Linux. Jeder Prozess mit ausreichenden Rechten kann ptrace auf einem anderen Prozess anwenden mithilfe des ptrace Kernel-Aufrufs. ptrace gewährt weitreichenden Zugriff auf den Prozess, einschließlich dessen Speicher, dessen Ressourcen (wie z. B. Dateideskriptoren) und die Möglichkeit zum Abfangen von Kernel-Aufrufen des Prozesses.
• docker exec
  docker exec ist ein Dienst des Docker-Daemons, der den Start eines zusätzlichen Prozesses innerhalb eines vorhandenen Containers ermöglicht. Dies wird oft dazu eingesetzt, um den Container zu untersuchen oder manuelle Änderungen vorzunehmen. Um beispielsweise zwecks Debugging eine Bash-Shell innerhalb des infizierten Containers zu starten, könnten Sie Folgendes ausführen:
  docker exec -it container-name /bin/bash
• nsenter
  ​ nsenter ist ein Linux-Dienstprogramm zum Starten oder Verlegen von Prozessen innerhalb bestimmter Namensräume. Da Container auf Linux-Namensräumen basieren, kann nsenter als eine allgemeinere Version von docker exec verwendet werden.
• Kernel Capabilities
  In Linux wurden die Sonderrechte, die normalerweise dem root -Account vorbehalten sind, in einzelne Capabilities aufgeteilt, die administrative Rechte von unterschiedlichem Umfang gewähren. Beispielsweise gewährt CAP_SYS_TIME nur das Recht, die Systemzeit einzustellen. CAP_SYS_ADMIN dagegen gewährt die gesamte Bandbreite an Rechten, die zur Administration eines Rechners notwendig sind. Jede Kernel-Capability kann einem Prozess explizit gewährt oder verweigert werden.
• seccomp
  Das seccomp Linux-Dienstprogramm ermöglicht individuelle Zugriffe auf Kernel-Aufrufe.

Red Hat Product Security hat die Sicherheitsauswirkungen dieses Updates als moderat eingestuft.

Betroffene Produkte

Folgende Red Hat Produktversionen sind betroffen:

• Red Hat Enterprise Linux 7
• Red Hat Openshift Container Platform
• RHEL Atomic Host

Auswirkung

Die in CVE-2016-9962 beschriebene Schwachstelle tritt auf, weil ein Sicherheitsmechanismus in docker exec fehlt.

Bis zur Upstream-Docker-Version 1.12.6 konnte auf den von docker exec gestarteten Prozessen ptrace innerhalb des Containers angewendet werden, und die Prozesse behielten noch kurz ihre Dateideskriptoren, die mit Inhalten außerhalb des Containers verknüpft waren. Dies konnte von einem Prozess innerhalb eines Containers, der mit ptrace Fähigkeiten ausgestattet ist, ausgenutzt werden. Falls ein bösartiger Prozess schnell genug handelte, konnte er ptrace auf dem eingehenden Prozess anwenden und Zugriff auf Inhalte außerhalb des Containers erlangen. Dies wurde in Docker 1.12.6 behoben, indem das Ausführen von ptrace auf diesen Prozessen (mittels DUMPABLE Prozessattribut) unterbunden wurde und eingehende Prozesse nunmehr ihre Dateideskriptoren bereinigen, bevor sie verlegt werden.

Auch ohne Backport sind die meisten Installationen nicht gefährdet:

• Die Docker-Laufzeitumgebung entfernt standardmäßig viele der Kernel-Capabilities von Containern, darunter CAP_SYS_PTRACE . Das bedeutet, dass nur Container, denen diese Capability ausdrücklich zugewiesen wurde (oder die mit dem --privileged Switch ausgeführt werden) gefährdet sind. Darüber hinaus stellen nur privilegierte Prozesse innerhalb dieser Container ein Risiko dar. Unprivilegierte Benutzerprozesse in diesen Containern verfügen nicht über genügend Rechte, um Schaden anrichten zu können. Vorausgesetzt, Sie folgen den empfohlenen Verhaltensweisen und führen „keine privilegierten Container“ und „keine Root-Prozesse innerhalb von Containern“ aus, dann sind Sie demzufolge sicher.
• Auf Red Hat Systemen mit aktivem SELinux werden selbst die Gefahren von privilegierten Containern verhindert. SELinux hindert Container-Prozesse am Zugriff auf Host-Inhalte, selbst wenn diese Container-Prozesse Zugriff auf die jeweiligen Dateideskriptoren erlangen sollten.
• In den meisten Installationen sind nsenter und docker exec ausschließlich manuelle Operationen. OpenShift verwendet nsenter für Port-Weiterleitung; ohne manuellen Eingriff wird Vanilla Docker jedoch niemals einen Prozess in einen Container oder zwischen Containern verschieben.

Diagnostizieren Ihrer Anfälligkeit

Um zu überprüfen, ob Ihre Docker-Version bereits die zurückportierte Fehlerbehebung enthält, laden Sie dieses Skript herunter und führen es aus.