bk99.de entertain the web since 1997

bk99.de
fefe · SicherheitKuratiert

Der Einbruch auf kernel.org

Zusammenfassung

Im Spätsommer 2011 wurde kernel.org gehackt, der zentrale Server, von dem aus die Linux-Quellen in die Welt gespiegelt werden. Felix von Leitner, selbst mit Konto auf dem System, erklärte die Lage: Angreifer kamen über das gestohlene Konto eines Nutzers herein, verschafften sich Root-Rechte und installierten ein Rootkit samt manipuliertem SSH. Die Kernel-Quellen selbst waren nach dieser Darstellung nicht gefährdet, weil Git jede Änderung mit kryptografischen Prüfsummen absichert.

Warum der Kernel sicher blieb

Git ist ein verteiltes Versionskontrollsystem. Die maßgeblichen Kernel-Quellen liegen nicht nur auf kernel.org, sondern bei Linus Torvalds und unzähligen Entwicklern. Jeder Stand wird durch eine Prüfsumme identifiziert, die von der gesamten Vorgeschichte abhängt. Eine heimliche Änderung in der Vergangenheit würde beim nächsten Abgleich sofort auffallen.

Trotzdem prüften die Betreiber vorsichtshalber alle kürzlich hochgeladenen oder veränderten Archive.

Was der Fall zeigt

Das gestohlene Konto hatte keine Root-Rechte, das Rootkit schon. Es gab also mindestens eine damals unbekannte Lücke zur Rechteausweitung unter Linux. kernel.org war wochenlang offline und wurde neu aufgebaut. Seitdem brauchen Entwickler für Schreibzugriff einen PGP-Schlüssel, der im Vertrauensnetz der Kernel-Entwickler verankert ist.

Ideen

  • Verteilte Versionskontrolle macht einen einzelnen kompromittierten Server weniger gefährlich.
  • Kryptografische Prüfsummen über die ganze Geschichte machen Manipulationen sichtbar.
  • Ein gestohlenes Nutzerkonto plus lokale Rechteausweitung reicht für die volle Kontrolle.

Einsichten

  • Auch die erfahrensten Teams sind nicht vor Einbrüchen gefeit.
  • Integrität lässt sich durch Kryptografie absichern, Verfügbarkeit nicht.

Fakten

  • Der Einbruch auf kernel.org wurde im August 2011 entdeckt.
  • Die Angreifer kamen über ein legitimes Nutzerkonto ohne Root-Rechte herein.
  • kernel.org war danach wochenlang offline und wurde neu aufgebaut.

Referenzen

Bemerkungen

  • Seit dem Vorfall setzt kernel.org für Schreibzugriff auf PGP-Schlüssel im Vertrauensnetz der Entwickler.

Empfehlungen

  • Prüfe heruntergeladene Quellen über Signaturen oder Git-Prüfsummen statt dem Server zu vertrauen.
  • Behandle jede lokale Rechteausweitung als ernste Lücke, auch auf Systemen mit vertrauenswürdigen Nutzern.

Originalbeitrag lesen →

Im Webarchiv suchen

fefe · 2018

Hardwarefehler erzwingt teure Kernel-Schutzmaßnahmen

Anfang Januar 2018 kursierten Gerüchte über einen Hardwarefehler in Prozessoren, gegen den die Kernel-Entwickler eilig teure Schutzmaßnahmen einbauten. Felix von Leitner hielt den Verlust von ASLR zunächst für verschmerzbar, weil ASLR nur die Ausnutzung von Lücken erschwert. Ein Nachtrag korrigierte: Offenbar konnten normale Programme Kernelspeicher auslesen, und das ist ernst.

fefe · 2016

Android-Patches offenbaren kritische Kernel-Lücken

Das Android-Sicherheitsbulletin vom Oktober 2016 enthielt kritische Lücken, die nach allgemeinen Linux-Problemen klangen, darunter Codeausführung aus der Ferne im ASN.1-Decoder und im Netzwerk-Subsystem des Kernels. Felix von Leitner kritisierte, dass die Linux-Entwickler solche Lücken nicht klar ankündigten. Ein Nachtrag relativierte: Die Netzwerklücke betraf nach erster Durchsicht nur Programme, die den selten genutzten Systemaufruf recvmmsg verwenden.

fefe · 2009

Verschweigt Linux sicherheitsrelevante Kernel-Patches?

Felix von Leitner kritisierte 2009, dass die Linux-Entwickler nicht mehr kennzeichneten, welche Kernel-Patches Sicherheitslücken schließen. Als Beispiel diente Linux 2.6.29.1 mit einer Änderung im CIFS-Code, die nach einem Pufferüberlauf aussah, der aus der Ferne ausnutzbar sein könnte. Ohne Hinweis bemerkten weder normale Nutzer noch Fachmedien, wie dringend das Update war.