Docker – Genauso schlimm wie befürchtet

Jetzt ist es also endlich soweit, jemand hat man genauer hingeschaut und Dockerimages auf Schwachstellen untersucht. Das Ergebnis: Es ist genauso schlimm wie das von den Skeptikern erwartet wurde!

Kaum Sicherheitsupdates

Zunächst mal zur Quelle der Daten:

https://snyk.io/blog/top-ten-most-popular-docker-images-each-contain-at-least-30-vulnerabilities/

Da ist eine schöne Grafik über die Anzahl der gefundenen Schwachstellen per speziellem Dockercontainer. Das NODE dabei übelst abgeschnitten hat, wundert mich seit meinen Kontakten damit nicht im geringsten. Ohne darauf groß einzugehen, eine Repoumgebung, die zig Versionen der gleichen Erweiterung bereithält, anstatt nur die mit den wenigsten Löchern drin, kann man nicht ernsthaft als Basis für irgendwas benutzen.

Jetzt zur Analyse oben

Die Skeptiker, Altbackenden, Konservativen, die Im-Weg-Steher hatten es von Anfang an gesagt:

Wenn man Apps in Container packt und eine für diese App gangbare Umgebung dazu legt, dann wird man am Ende jede Menge Container mit Sicherheitslücken haben. Und genau das ist dabei rausgekommen. Weil sie keiner updated, obwohl das möglich ist, dümmpelt eine Sicherheitslücke neben der anderen rum.

Der sicherere Ansatz ist und bleibt, daß jemand das OS vorgibt und sich die Apps an die Umgebung anpassen müssen. Damit sind die gezwungen Updates zu machen und das dient dann der allgemeinen Sicherheit.

QED. Und es wurde gerade demonstriert!

Abzulehnen ist also alles, was eine App installiert, die mit eigener Umgebung kommt, sowas wie FlatPak, Docker und Snap.

 

min. 4 schwere Schwachstellen im HTTP/2 Protokoll

Sicherheitsforscher haben auf der Black Hat Conference 4 neue Angriffe gegen die serverseitigen Implementierungen des HTTP/2 Protokolls vorgestellt.

HTTP/2 soll das Netz beschleunigen, weil man mehrere Webseiten über eine bestehende Verbindung abrufen kann. Da Overhead durch ständiges Auf- und Abbauen von Verbindungen wird so vermieden. Das Problem, genau das führt jetzt zu neuen Angriffen, welche die neuen Mechanismen in einer schadhaften Weise gebrauchen. Dabei sind Angriffe möglich, die im HTTP/1.1 schon funktioniert haben, und im HTTP/2 nicht schon im Keim erstickt wurden.

Ob man dazu allerdings die Slow Read Attacke (CVE-2016-1546) zählen kann, bei der nur jeweils 1 Byte von einer Ressource angefragt wird und so legitimer Traffic vorgetäuscht wird, weiß ich allerdings nicht. Machbar ist sie jedenfalls.

Schon sehr viel spannender, die HPACK Bombe (CVE-2016-1544, CVE-2016-2525) : Dabei schickt der Client extrem komprimierte Header im Request mit, die beim Server ein Out-Of-Memory auslösen und damit ggf. einen DOS oder sogar einen Crash verursachen.  Das Ganze funktioniert nach dem ZIP-Bombenprinzip. Dabei wird aus einer unscheinbaren kleinen Datei GB an unkomprimierten Daten. Das stellt man sich als Laie so vor, daß der Kompressionsalgorithmus so funktioniert:  „AAABBBBBCCCCCCDDDDD“ wird zu 3A5B6C4D, was deutlich kürzer ist. Wenn man jetzt 1000000000A schreibt, ist das extrem kurz, wäre nach dem Auspacken aber 1 Milliarde Byte groß ( was fast, aber eben nur fast, ein GB ist 😉 ) . Hat man nun mehrere dieser Header und mehrere dieser Anweisungen muß der Server schon mehrere GB RAM aufwenden, was er nicht machen können wird, wenn das mehrfach an den Server geschickt wird. Dazu kommt dann noch die CPU Belastung durch die unnützen Dekomprimierungen.

Die Dependency Cycle Attack (CVE-2015-8659) erlaubt es dem Angreifer, die im HTTP/2 vorgesehenen Netzwerkoptimierungen zu beeinflussen und in eine Endlosschleife zu zwingen. Da es auch zum Crash kommen kann, ist es hier durchaus möglich, das der Angreifer so Code auf dem Server zur Ausfnührung bringen kann.

Die Stream Multiplexing Abuse (CVE-2016-0150)  erlaubt es dann dem Angreifer in ähnlicherweise die Datenströme der Verbindungen im Server so durcheinander zu bringen, daß  dieser abstürzt.

In aktuellen HTTP/2 Implementierungen sind diese Fehler auf  allen gängigen Webserver behoben worden, aber wer sowas wie die HPACK Bomb beim Planen seines Protokolls nicht berücksichtigt, der baut da auch unwissentlich noch mehr Designfehler ein. Wir dürfen uns also darauf freuen, an der Front in Zukunft noch einiges an originellen Angriffen erleben zu dürfen.

Diagramme und weitere Infos gibt es im Link unten.

Quelle: thehackernews.com