Kernel- und Treiberprogrammierung mit dem Kernel 2.6 -

Kernel- und Treiberprogrammierung mit dem Kernel 2.6 -

Angriffe über Buffer Overflows haben es schwerer, wenn Address-Space Layout Randomization (ASLR) oder die Hardware-Unterstützung durch NX- und XD-Bits aktiv ist. Die Implementation der 32-Bit-Architektur bietet Linux-Hackern viele Möglichkeiten zur Absicherung.

Als Multiusersystem ist Unix aus Tradition der Sicherheit verpflichtet. Zutrittsschutz mit Benutzername und Passwort, die Unterscheidung zwischen Superuser und übrigen Benutzern sowie Dateizugriffsrechte, die lesenden, schreibenden und ausführenden Zugriff für den Besitzer, eine Gruppe und den Rest getrennt festlegen, waren Unix schon in die Wiege gelegt.

Heute reichen diese Schutzmechanismen nicht mehr aus, um aktuelle Methoden von Angreifern abzuwehren. Häufiger Angriffsvektor sind Buffer Overflows. Bei diesem Angriff nutzen die Exploits der Black Hats zumeist Programmierfehler aus, die es ihnen ermöglichen, Speicherbereiche zu überschreiben.

Tun sie dies auf dem Stack und modifizieren die dort befindliche Rücksprungadresse einer Unterfunktion, bringen sie die CPU dazu, beim »return« der Funktion eigenen Code anzuspringen. Dieser liegt meist auf dem Stack. Noch bequemer ist es, eine Bibliotheksfunktion – zum Beispiel »system()« der Libc – anzuspringen. So gewinnt der Angreifer Kontrolle über die Maschine (siehe Abbildung 1). Zwei Voraussetzungen spielen den Angreifern in die Hände: Die starre Aufteilung des Adressraums und die Möglichkeit, auf dem Stack befindlichen Code auszuführen.

Abbildung 1: Gelingt es einem Angreifer, mehr Daten in einem Buffer auf dem Stack abzulegen, als der Programmierer dafür vorgesehen hat, kann er beim Buffer Overflow die gültige Rücksprungadresse überschreiben. Beim Rücksprung führt die CPU dann mitunter bösartigen Code aus.

Angriffsmuster

Genau an diesen Stellen setzt der Linux-Kernel an, um Black Hats die Arbeit zu erschweren. Richtig konfiguriert verhindert es der Kernel mit Hardwarehilfe des Prozessors, Code auf dem Stack auszuführen. Außerdem kann er jeder Applikation ein eigenes, durch den Zufall bestimmtes Speichermapping verpassen. Diese Eigenschaften muss der Anwender jedoch auch nutzen.

Speichermapping bezeichnet die Aufteilung des virtuellen Adressraums in Code, Daten, Stack, Heap und Bibliotheken eines Programms. Jeder Applikation stehen auf einem 32-Bit-Linux typischerweise 3 GByte Hauptspeicher zur Verfügung, unabhängig davon, ob nur 64 MByte oder 4 GByte RAM im Rechner stecken. Ohnehin nutzen nur wenige Programme den virtuellen Adressraum vollkommen aus. Somit verteilt Linux die einzelnen Teile des Kernels sinnvoll über den Adressraum von 3 GByte, wie Abbildung 2 illustriert.

Abbildung 2: Im Normalfall ist die Einteilung des Adressraums auf einem 32-Bit-System der I-386-Architektur festgelegt. Heap und Stack wachsen von zwei Seiten aufeinander zu, da ihre Größe dynamisch wächst.

Ziemlich am Anfang befinden sich der Code des Programms, die vorinitialisierten (Data) und die nicht vorinitialisierten Daten (BSS), der Stack und der Heap. Der Heap ist der Speicherbereich, den etwa »malloc()« als Basis für dynamisch angeforderten Speicher verwendet. Die gemeinsam genutzten Bibliotheksfunktionen (Dynamic Shared Objects, DSO) blendet der Kernel ebenfalls in den Adressraum ein, etwa Speicherseiten, die eine Applikation per »mmap()« von anderen Prozessen angefordert hat.

Da beim Start eines Prozesses nicht bekannt ist, wie viel Arbeitsspeicher er dynamisch anfordern wird oder wie viele Speicherseiten er per »mmap()« verwenden will, wachsen die Heap- und die Mmap-Region aufeinander zu. Für den Stack, dessen Verbrauch beim Start ebenfalls nicht bekannt ist, reserviert der Kernel innerhalb des Adressraums einfach 128 MByte, falls nichts anderes konfiguriert ist.

Hackerfreundlich

Bei einer derart starren Aufteilung des virtuellen Adressraums ist es für Angreifer leicht, Rücksprungadressen auf dem Stack mit eigenen Adressen zu überschreiben. Daher bringt der Linux-Kernel – sofern gewünscht – mehr Variationen bei der Lage der Adressbereiche ein und verschiebt die Position des Stacks und der Mmap-Region, in der sich auch die gemeinsam genutzten Bibliotheken (DSO) befinden. Bei so verwürfeltem Speichermapping kommen Angreifer nur noch mit Ausprobieren weiter. Raten sie dabei falsch, stürzt die angegriffene Applikation mit hoher Wahrscheinlichkeit ab. Aufmerksamen Anwendern und Admins fällt das auf.

Verwandte Artikel

Editorial

Ihre stets als Vorteil angepriesene dezentrale Struktur könnte der Kryptowährung Bitcoin angesichts des dringend notwendigen Updates auf eine Post-Quantum-Verschlüsselung demnächst auf die Füße fallen.

Linux 6.12 LTS im Überblick

20 Jahre lang pflegten die Entwickler die Echtzeitunterstützung außerhalb des Mainline-Kernels. Jetzt avanciert sie mit Linux 6.12 zum offiziellen Teil des Betriebssystemkerns.

NASA: Open Source seit 1958?

Nach dem Sputnik-Schock gegründet, hat die NASA in den über sechzig Jahren ihres Bestehens stets offene und freie Projekte gestartet und gefördert. Ohne Open Source und Open Science wären zahlreiche davon unmöglich, wissenschaftlicher Fortschritt viel schwerer.

Open Source bei der European Space Agency

Anders als die NASA ist die ESA dezentral organisiert, international und kommerziell orientiert. Obwohl sie auch deutlich weniger Top-Down aufgebaut ist, gibt es Fesseln, die Open Source nicht immer in dem Umfang erlauben, den die Agency als auch die Wissenschaftler wünschen. Doch das ändert...

Wie Firmen aus der Raumfahrtbranche OpenProject einsetzen

OpenProject ist eine der komplexeren Open-Source-Anwendungen und beweist auch in der Raumfahrtindustrie, dass Open Source selbst komplexen Aufgabenstellungen gewachsen ist.

In eigener Sache: DELUG-DVD

Auf der Heft-DVD finden Sie diesmal das aktuelle Grml 2024.12, den Animationsfilm "Ada und Zangemann", 16 Videos von der 38C3, ein E-Book über Flat File CMS, den Proxmox Backup Server 3.3 und vieles mehr.