Dirty COW erklärt – wie schlimm ist die Security-Lücke für Linux , Android oder Dein System?
Bei linux.com gibt es eine sehr gute, ausführliche und vor allen Dingen verständliche Erläuterung zum Thema Dirty COW. Dort wird Dir erklärt, was Dirty COW macht, wie schlimm die Security-Lücke ist und wie Du Dich dagegen wehren kannst. Beziehungsweise wird Dir klar, ob es Dich überhaupt betrifft oder nicht.
Warum eigentlich Dirty COW?
Es handelt sich hierbei um ein Wortspiel, das sich von Copy on Write ableitet. Eigentlich wird die Security-Lücke recht langweilig als CVE-2016-5195 bezeichnet. Mir hätte der Zusatz gefallen: Die zarteste Versuchung, seit es Exploits gibt!
Dort ist zu lesen, dass die Security-Lücke eine Race Condition im Speicher-Subsystem des Linux-Kernels ist.
Die Security-Lücke wird bereits aktiv ausgenutzt. Die Kacke ist also am Dampfen.
Die Schwere einer Lücke lässt sich auch anhand des Fakts einschätzen, ob sie einen eigenen Namen / eigene Grafik bekommt. Heartbleed zum Beispiel oder GHOST. Oder das hier.
Für Dirty COW gibt es einen Fix
Die gute Nachricht ist, dass es einen Fix im Upstream Kernel gibt. Ebenfalls haben die Distributionen bereits Kernel-Patches / Aktualisierungen zur Verfügung gestellt. Auf jeden Fall lohnt es sich, ein Auge auf die Updates in den kommenden Tagen zu halten und wer wöchentlich aktualisiert, sollte vielleicht eine Ausnahme machen. Als Distribution gilt übrigens auch Android und das ist pikant. Es gibt genug Hersteller, die ältere Geräte nicht fixen. Die schmutzige Kuh suhlt sich bereits seit zirka neun Jahren im Kernel.
Wer also eine Linux-Distribution oder Android-Version im letzten Jahrzehnt installiert oder eingesetzt hat, der hat den Bug mit ziemlicher Sicherheit im System. Noch blöder ist die Sache, da sämtliche embedded Geräte ebenfalls betroffen sein können. Aktualisiert werden die aber nicht mehr. Alte Router sind ein Beispiel, die verwundbar in der Ecke laufen könnten und zusätzlich das admin/admin-Problem haben.
Die Entwickler raten dringend zu einem baldigen Update. Sie gehen davon aus, dass die bösen Buben einfach auszuführende Exploits für die Security-Lücke suchen. Das bedeutet im Endeffekt, root zu werden. Nach dem Einspielen eines Patches oder dem Update des Kernel ist ein kompletter Neustart notwendig. Das ist nur dann nicht der Fall, wenn eine Live-Patching-Lösung am Start ist.
Dummerweise helfen SELinux, AppArmor und so weiter nicht gegen diesen Bug. Auch PaX/GrSecurity Hardening Patches sind unwirksam. Es hilft also wirklich nur ein Update.
Die Entwickler von Raspian, der offiziellen Distribution für den Raspberry Pi, stellen ebenfalls einen Patch zur Verfügung. Er lässt sich sehr einfach einspielen.
Der Angreifer muss zunächst Zugriff auf das System haben
Noch einmal eine gute Nachricht oder eine, die etwas Durchschnaufen lässt. Dirty COW lässt sich nicht einfach von außen abfeuern und der Angreifer hat root-Rechte auf Deinem System.
Um Dirty COW erfolgreich ausführen zu können, muss der Angreifer zunächst beliebigen Code auf Deinem System ausführen können. Das ist eigentlich schon schlimm genug, selbst wenn sich der böswillige Hacker keine root-Rechte ergaunern will.
Allerdings kannst Du Dir nie sicher sein, ob es weitere Fehler im Kernel gibt. Sie könnten wie Dirty COW schon jahrelang dort schlummern und die Angreifer kennen die Security-Lücken. In Kombination mit Dirty COW ergeben sich dann möglicherweise ganz schlimme Szenarien.
Deswegen ist es sehr wichtig, eine Security-Strategie einzusetzen, durch die Angreifer erst gar nicht auf das System kommen. Wie gesagt, kann ich die Kuh nur aufs Glatteis führen, wenn ich Code auf dem System ausführen darf. Kein Systemzugriff -> keine schmutzige Kuh.
COW erklärt
Der Schreiber erklärt die Security-Lücke Dirty COW sehr einfach und verständlich. Man nehme folgenden Code:
a = 'COW'
b = a
Das sind zwei Variablen, die aber auf das gleiche Speicherobjekt zeigen. Somit muss der Speicher auch nicht doppelt belastet werden. Das Betriebssystem wartet nun, bis der Wert des Duplikats modifiziert wird:
b += ‘ Dirty’
Nun passiert vereinfacht gesagt das:
- Für die neue und modifizierte Version des Objekts wird Speicher zugewiesen
- Lese den Original-Inhalt des Objekts, das dupliziert wird (COW)
- verarbeite die Änderungen ( Dirty hinzufügen)
- Schreibe den veränderten Inhalt in den neu zugewiesenen Bereich des Speichers.
Blöderweise liegt zwischen den Schritten 2 und 4 die bereits angesprochene Race Condition. Im Endeffekt bewirkt das, dass die veränderten Inhalte in den ursprünglichen Bereich des Speichers geschrieben werden und nicht in den neu zugewiesenen. Was also b hätte modifizieren sollen, hat a verändert.
Durch das Ausnutzen der Race Condition könnte ein Angreifer DAC (Discretionary Access Controls) umgehen. Als Beispiel wird /bin/bash angegeben. Lieschen Müller darf diese Datei nur lesen (read), aber nicht verändern. Der Anwender root darf /bin/bash tauschen und wenn Du Dir nun das oben erklärte Szenario dazu vorstellst. Sollte sich so eine häufig verwendete Datei in etwas schädliches verwandeln – das ist nicht gut. Eine verseuchte /bin/bash könnte zum Beispiel Passwörter mitlesen und so weiter.
Fazit
So schnell wie möglich Kernel updaten!!!
Du hast da einen kleinen Fehler drin. COW steht für Copy-on-Write, nicht Change-on-Write.
Danke für den Hinweis! Da hast Du vollkommen Recht ... man soll einfach nicht mehrere Dinge gleichzeitig machen ... ist ausgebessert