© best_vector/Shutterstock.com
Windows Developer
Ist Docker so unsicher, dass wir eine Alternative brauchen?

Docker-Sicherheit im Überblick

Docker isoliert Anwendungen in Container. Aber ist das auch sicher? Manche meinen, nein - und bringen eine Alternative an den Start. Sollte man also um Docker einen Bogen machen, wenn einem die Sicherheit der eigenen Systeme am Herzen liegt? Oder sind die Bedenken übertrieben?

Carsten Eilers


Anwendungen in virtualisierten Umgebungen auszuführen, kann deren Sicherheit und die des gesamten Systems erhöhen. Nicht ohne Grund werden heutzutage (nicht nur) potenziell gefährliche Programme oder Programmteile in Sandboxes ausgeführt. Zwei gute Beispiele sind der Internet Explorer und der als Angriffsziel lange Zeit sehr beliebte Adobe Reader. Beide reduzieren die Folgen eines möglichen Angriffs, indem sie die entsprechenden Prozesse in eine Sandbox sperren. Apple sperrt unter iOS gleich die kompletten Apps in jeweils eigene Sandboxes – und fährt damit recht gut.

Allerdings gibt es diesbezüglich ein großes „Aber“: Denn dieses Vorgehen funktioniert nur, wenn der Code in der Sandbox oder der virtuellen Umgebung keine Möglichkeit hat, aus seinem „Gefängnis“ auszubrechen und entweder andere Anwendungen oder das zugrunde liegende Betriebssystem zu kompromittieren. Es gab bereits reichlich Beweise, sowohl in der Theorie als auch in der Praxis, dass diese Ausbrüche möglich sind, und das bei den speziell auf Sicherheit ausgerichteten Sandboxes. Wie viel leichter muss der Ausbruch also erst sein, wenn die virtuelle Umgebung nicht besonders gehärtet ist? Container sind noch einmal eine Nummer unsicherer, da sie nicht vollständig virtualisiert sind, sondern vieles mit dem zugrunde liegenden Betriebssystem teilen. Und im Fall von Docker gibt es darüber hinaus noch weitere Kritikpunkte. Aber immer der Reihe nach. Los geht es im Juni 2014.

18. Juni – Der erste „Exploit“ für Docker

Am 9. Juni 2014 wurde Docker 1.0.0 veröffentlicht [1], und schon am 18. Juni folgte der erste Exploit, der einen Ausbruch aus dem Container erlaubt [2]. Jedenfalls, wenn man einigen Medien glaubt, die daraus teilweise eine Gefahr für Docker konstruiert haben. Aber was war wirklich passiert? Die Docker-Entwickler haben in Version 1.0 eine Kernel-Capability (CAP_DAC_READ_SEARCH) entfernt, die den Zugriff auf beliebige Dateien außerhalb des eigenen Containers erlaubte. Nebenbei bemerkt wurden noch viele weitere Kernel-Capabilities entfernt, da man von einer Blacklist verbotener Capabilities zu einer Whitelist erlaubter Capabilities gewechselt ist.

Daraufhin hat Sebastian Krahmer, der die Schwachstelle in Docker 0.11 entdeckt hatte, ein Security Advisory samt Proof of Concept [3] (PoC) veröffentlicht. Es wurde also kein Exploit für eine neue Schwachstelle (also ein 0-Day Exploit) „in the wild“ entdeckt, sondern für eine bereits behobene Schwachstelle ein PoC veröffentlicht. Das kommt ständig v...

Windows Developer
Ist Docker so unsicher, dass wir eine Alternative brauchen?

Docker-Sicherheit im Überblick

Docker isoliert Anwendungen in Container. Aber ist das auch sicher? Manche meinen, nein - und bringen eine Alternative an den Start. Sollte man also um Docker einen Bogen machen, wenn einem die Sicherheit der eigenen Systeme am Herzen liegt? Oder sind die Bedenken übertrieben?

Carsten Eilers


Anwendungen in virtualisierten Umgebungen auszuführen, kann deren Sicherheit und die des gesamten Systems erhöhen. Nicht ohne Grund werden heutzutage (nicht nur) potenziell gefährliche Programme oder Programmteile in Sandboxes ausgeführt. Zwei gute Beispiele sind der Internet Explorer und der als Angriffsziel lange Zeit sehr beliebte Adobe Reader. Beide reduzieren die Folgen eines möglichen Angriffs, indem sie die entsprechenden Prozesse in eine Sandbox sperren. Apple sperrt unter iOS gleich die kompletten Apps in jeweils eigene Sandboxes – und fährt damit recht gut.

Allerdings gibt es diesbezüglich ein großes „Aber“: Denn dieses Vorgehen funktioniert nur, wenn der Code in der Sandbox oder der virtuellen Umgebung keine Möglichkeit hat, aus seinem „Gefängnis“ auszubrechen und entweder andere Anwendungen oder das zugrunde liegende Betriebssystem zu kompromittieren. Es gab bereits reichlich Beweise, sowohl in der Theorie als auch in der Praxis, dass diese Ausbrüche möglich sind, und das bei den speziell auf Sicherheit ausgerichteten Sandboxes. Wie viel leichter muss der Ausbruch also erst sein, wenn die virtuelle Umgebung nicht besonders gehärtet ist? Container sind noch einmal eine Nummer unsicherer, da sie nicht vollständig virtualisiert sind, sondern vieles mit dem zugrunde liegenden Betriebssystem teilen. Und im Fall von Docker gibt es darüber hinaus noch weitere Kritikpunkte. Aber immer der Reihe nach. Los geht es im Juni 2014.

18. Juni – Der erste „Exploit“ für Docker

Am 9. Juni 2014 wurde Docker 1.0.0 veröffentlicht [1], und schon am 18. Juni folgte der erste Exploit, der einen Ausbruch aus dem Container erlaubt [2]. Jedenfalls, wenn man einigen Medien glaubt, die daraus teilweise eine Gefahr für Docker konstruiert haben. Aber was war wirklich passiert? Die Docker-Entwickler haben in Version 1.0 eine Kernel-Capability (CAP_DAC_READ_SEARCH) entfernt, die den Zugriff auf beliebige Dateien außerhalb des eigenen Containers erlaubte. Nebenbei bemerkt wurden noch viele weitere Kernel-Capabilities entfernt, da man von einer Blacklist verbotener Capabilities zu einer Whitelist erlaubter Capabilities gewechselt ist.

Daraufhin hat Sebastian Krahmer, der die Schwachstelle in Docker 0.11 entdeckt hatte, ein Security Advisory samt Proof of Concept [3] (PoC) veröffentlicht. Es wurde also kein Exploit für eine neue Schwachstelle (also ein 0-Day Exploit) „in the wild“ entdeckt, sondern für eine bereits behobene Schwachstelle ein PoC veröffentlicht. Das kommt ständig v...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang