Lücken im Kernel: So brechen Hacker in jeden Rechner ein

Im Gegensatz zu lokalen Attacken, gibt es deutlich weniger Netzwerkangriffe, die dem Angreifer erlauben, Kernel-Mode-Code auszuführen. Allerdings besteht ein starkes Ungleichgewicht zwischen Windows und Linux. Für Linux ist die Zahl der bekannten Angriffsmöglichkeiten recht überschaubar. Der Windows-Kernel hingegen lässt sich durch zahlreiche bekannte Angriffe austricksen.

Das Hauptproblem unter Linux ist nicht anders als bei Windows: Viele Treiber von Drittherstellern sind mit zahllosen Bugs behaftet, die ein Eindringen in den Kernel von außen ermöglichen. Laut Ormandy und Tinnes handelt es sich dabei vor allem um WLAN-Treiber. Allerdings ist etwa auch ein Grafiktreiber von Nvidia mit einem Bug bekannt, der einen Angriff von außen ermöglicht. Er ist jedoch schon vor vier Jahren behoben worden.

Um einen Linux-Rechner mit fehlerhaftem WLAN-Treiber von außen aktiv anzugreifen, muss man in der Regel speziell modifizierte WLAN-Pakete senden, was die Reichweite eines solchen Angriff natürlich begrenzt. Falls jedoch IP-Routing aktiviert ist, kann man solche Pakete theoretisch auch über das Internet senden. Der Rechner leitet sie an das WLAN-Interface weiter. Generell gilt natürlich für alle Rechner, die aus dem Internet erreichbar sind, dass sämtliche Treiber von Consumer-Devices dort nichts verloren haben.

Ein weiterer inzwischen beseitigter Bug betrifft das SCTP-Protokoll, das oberhalb von IP auf demselben OSI-Layer wie TCP und UDP steht. Es wird von einigen VoIP-Carriern eingesetzt, ist aber auf Standard-Linux-Rechnern nicht installiert. Ein verwundbarer Rechner konnte seinerzeit angegriffen werden, indem man ihm über das Internet bestimmte SCTP-Pakete sandte.

Die Google-Sicherheitsexperten weisen darauf hin, dass es noch einige andere Netzwerklücken gegeben hat, mit denen man in den Kernel eindringen konnte, erwähnen sie aber nicht explizit.

Unter Windows sieht es ganz anders aus: So sind für Windows eine ganze Reihe von Netzwerk-Angriffen bekannt. Microsoft beseitigt sie bei Bekanntwerden recht schnell. Viele dieser Bugs befinden sich seit 1993 in Windows NT. Niemand weiß, ob sie von Cyberkriminellen ausgenutzt wurden, bevor sie jemand veröffentlicht oder an Microsoft gemeldet hat.

An erster Stelle nennen Ormandy und Tinnes eine Netzwerk-Einbruchsmöglichkeit in den Kernel, wo man sie eher nicht vermutet, nämlich Antiviren- und Firewallprogramme für Windows. Viele Kernelmodule dieser Programme seien so buggy, das man sie leicht für Kernel-Hacks ausnutzen kann.

Weitere Angriffspunkte seien das GDI, dass Microsoft aus Performancegründen in den Kernel verlegt hat. Auch der TCP/IP-Stack habe Bugs, beispielsweise die von Neel Mehta entdeckte Lücke. Wenn der Protokollstack einen Bug hat, reicht es aus, dass ein Rechner im Internet erreichbar ist, um angegriffen zu werden. Der von Immunity demonstrierte SMBv2-Exploit hingegen lässt sich nur ausnutzen, wenn man den Dienst Fileserver erreichen kann, was typischerweise nur aus dem Intranet der Fall ist.

Themenseiten: Betriebssystem, Google, Hacker, Linux, Open Source, Security-Analysen, Windows

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

7 Kommentare zu Lücken im Kernel: So brechen Hacker in jeden Rechner ein

Kommentar hinzufügen
  • Am 8. Juni 2011 um 21:01 von Bachsau

    Absurder Gedanke
    Trotz aller Sicherheitsbedenken finde ich die Idee, den Kernel gegen sich selbst abzusichern eine recht absurde Idee. Man kann sich nicht selbst gleichzeitig etwas ermöglichen und verbieten.

    Man kann Menschen daran hindern, in einen Knast reinzukommen, oder aus ihm auszubrechen. Das hindert Gefangene aber nicht daran, sich gegenseitig auf die Schnauze zu hauen. Irgendwo ist immer ein totes Ende. Kommt drauf an, wie weit man gehen will mit der Sicherheit.

    > sollte man Microsofts Sicherheitsfestung Forefront einsetzen.
    Auch nicht schlecht. Wir verdienen Geld, indem wir Schutz für die Unzulänglichkeiten des eigenen Produks anbieten…

  • Am 9. August 2010 um 22:59 von DM

    Mehr Ausführlichkeit zur Übernahme aus einem virtuellen Server heraus gewünscht
    Wenn ich den Artikel richtig verstanden habe kann man also auch nur mit Zugang auf virtuelle Maschinen aus dieser „ausbrechen“ und den ganzen Server übernehmen? Ich dachte immer virtuelle Maschinen sollen sicher sein bisher. Ich kenne mich leider nicht genügend mit der Materie aus, aber es wäre ein sehr schöner weiterer Artikelvorschlag das zu erläutern. Aus den wenigen Sätzen wird mir nicht ganz klar wo genau Zugriff auf’s virtuelle und „echte“ System gemeint ist.

    • Am 20. August 2010 um 12:15 von Christoph H. Hochstätter

      AW: Mehr Ausführlichkeit zur Übernahme aus einem virtuellen Server heraus gewünscht
      Ein Einbruch in andere virtuelle Maschinen durch Kernel-Lücken ist möglich bei Containervirtualisierung (Virtuozzo, openVZ, lxc), nicht aber bei Vollvirtualisierung (VMware, Hyper-V, VirtualBox, kvm, etc.).

      Bei Vollvirtualisierung ist ein Einbruch möglich durch Fehler im Hypervisor. Der Hypervisor ist aber wegen der geringeren Angriffsfläche besser geschützt.

  • Am 6. August 2010 um 12:43 von nonanet

    Und nu?
    Alle Rechner abschalten oder was?

  • Am 5. August 2010 um 21:44 von User

    Darwin
    Schöner Beitrag. Aber weis jemand, wie das im Darwin Kernel von OS X aussieht? Ist da eine ähnliche Technik verbaut?

    • Am 20. August 2010 um 10:52 von Jo

      AW: Darwin
      mac ist unix/linux

      • Am 20. August 2010 um 12:05 von Christoph H. Hochstätter

        AW: AW: Darwin
        Unix ja! Linux Nein!

        Darwin ist ein Unix-Kernel basierend auf BSD und MACH. Hat mit dem Linux-Kernel nichts zu tun.

        Die Google-Forscher haben Mac OS X weitgehend außer Acht gelassen, da Mac OS kaum in öffentlichen Webservern eingesetzt wird.

        Die Sicherheitsabteilung von Google interessiert sich verständlicherweise in erster Linie dafür, ob und wie jemand aus dem Internet auf ihre Server einrechen kann.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *