Abo
  • Services:
Anzeige
Die Speicherverwaltung von C-Programmen führt oft zu Sicherheitslücken.
Die Speicherverwaltung von C-Programmen führt oft zu Sicherheitslücken. (Bild: Levee)

C-Programmierung: Schutz für Code Pointer

Die Speicherverwaltung von C-Programmen führt oft zu Sicherheitslücken.
Die Speicherverwaltung von C-Programmen führt oft zu Sicherheitslücken. (Bild: Levee)

Bugs in der Speicherverwaltung von C-Programmen gehören zu den häufigsten Sicherheitslücken. Da es aussichtslos sein dürfte, alle Lücken zu beheben, hat Mathias Prayer eine Strategie vorgestellt, mit der sich die meisten verhindern lassen.

Sogenannte Memory-Corruption-Lücken gehören zu den größten Problemen der IT-Sicherheit. Buffer Overflows und ähnliche Lücken werden zwar permanent gefixt, jedoch ist ihre Zahl so groß, dass es kaum realistisch ist, sie alle zu finden. Mathias Prayer hat auf dem 31C3 einen praktikablen Ansatz dargelegt, durch den sich die Ausnutzbarkeit von vielen C-Sicherheitslücken mit akzeptablen Performanceverlusten massiv eindämmen lässt.

Anzeige

Der Grund für die meisten derartigen Sicherheitslücken ist die Speicherverwaltung von C und C++. Ein Programmierer muss selbst darauf achten, dass die Grenzen von Speicherbereichen eingehalten werden und nicht auf ungültige Speicherbereiche zugegriffen wird. In der Vergangenheit gab es bereits eine Reihe von Ansätzen, um das Ausnutzen von Memory-Corruption-Lücken zu erschweren. Dazu gehören etwa sogenannte Stack Canaries, Data Execution Prevention und die Randomisierung des Speicherlayouts (ASLR). Diese Ansätze werden in aktuellen Systemen bereits eingesetzt, doch sie lassen sich häufig umgehen und bieten daher keinen wirklichen Schutz.

Ganz auf C verzichten?

Vielfach wird empfohlen, wenn möglich ganz auf die Nutzung von C zu verzichten und Programmiersprachen mit einer sicheren Speicherverwaltung einzusetzen. Prayer setzt dem entgegen, dass man selbst dann auf große Mengen an C-Code angewiesen sei. Wer beispielsweise ein Programm unter Linux in Python entwickelt, benötigt weiterhin die Python-Laufzeitumgebung, die Glibc und den Linux-Kernel, die alle in C geschrieben sind. Ein System komplett ohne C-Code zu entwickeln, versucht derzeit das Projekt Mirage OS, das auf dem Kongress ebenfalls mit einem Vortrag präsent war.

Prayer und sein Forscherteam wollen die Probleme des Speicherzugriffs innerhalb von C lösen. Auch dazu gibt es bereits einige Ansätze, doch diese sind mit hohen Performanceverlusten verbunden und häufig inkompatibel mit bestehendem Code. So baut das Projekt Softbound + CETS durch eine Erweiterung des Clang-Compilers von LLVM zusätzliche Checks in den generierten Code ein, um Zugriffe außerhalb zulässiger Speicherbereiche zu unterbinden. Das funktioniert zwar, die Performanceverluste liegen jedoch bei über 100 Prozent. Einen etwas weniger aufwendigen Schutz bietet Address Sanitizer, das Teil von Gcc und Clang ist. Doch auch Address Sanitizer hat Performancekosten von etwa 70 Prozent. Für den praktischen Einsatz ist das kaum realistisch, es wird daher auch hauptsächlich als Debugging-Tool genutzt.

Die Idee von Prayers Team: Anders als bisherige Ansätze wollen sie nicht alle Speicherzugriffe schützen, sondern nur Funktionspointer. Denn bei der Ausnutzung von Memory-Corruption-Lücken wird in aller Regel versucht, den Programmablauf durch Überschreiben von Funktionspointern zu beeinflussen. Dadurch bleiben die Performancekosten im erträglichen Rahmen, die allermeisten Sicherheitslücken werden trotzdem verhindert.

Drei unabhängige Schutzmechanismen

Das Projekt Levee ist eine Erweiterung des Clang-Compilers von LLVM. Der Quellcode ist auf Github veröffentlicht. Dabei gibt es drei Schutzmechanismen, die unabhängig voneinander genutzt werden können. Auf dem Stack werden bei Funktionsaufrufen die Rücksprungadressen gespeichert, außerdem werden dort lokale Variablen abgelegt. Klassische Buffer Overflows versuchen häufig, diese Rücksprungadressen zu überschreiben. Der Strategie von Levee ist es daher, die Variablen von Code-Rücksprungadressen zu trennen und zwei separate Stacks zu nutzen. Die Performancekosten sind laut Prayer praktisch vernachlässigbar und sogar geringer als die von Stack Canaries, die bisher bereits eingesetzt werden.

Weitere Schutzmechanismen von Levee sind Code Pointer Security (CPS) und Code Pointer Integrity (CPI). Bei Code Pointer Security werden Funktionspointer auf dem Heap in einem abgetrennten Speicherbereich abgelegt. Die Performancekosten liegen bei wenigen Prozent. Bei Code Pointer Integrity werden zusätzlich alle Variablentypen geschützt, in denen in Zwischenschritten Funktionspointer abgelegt werden. Dadurch wird der Schutz deutlich vollständiger, die Performancekosten sind allerdings auch höher und liegen bei etwa zehn Prozent.

Die Schutzmechanismen funktionieren bereits auf Mac OS X, FreeBSD und Linux. Unter Linux läuft das System allerdings laut Prayer bisher weniger stabil. Auch werden bis jetzt nur x86- und x64-Architekturen unterstützt. In einem Test gelang es dem Team von Prayer, ein komplettes FreeBSD-System mit den Schutzmechanismen von Levee zu kompilieren. Auch wichtige sicherheitskritische Anwendungen wie OpenSSL oder Apache ließen sich damit betreiben. Als nächster Schritt der Entwicklung sollen erste Teile des Codes in den offiziellen LLVM-Code zurückfließen. Am weitesten ist dabei die Separierung des Stacks, diese könnte schon bald Teil des offiziellen Clang-Compilers sein.


eye home zur Startseite
Cerdo 29. Dez 2014

Obwohl ich 3D-Drucker jetzt eher in den Maschinenbau-Bereich setzen würde.

Cerdo 29. Dez 2014

In C99 kannst du verwenden. Damit castest du automatisch zum längsten verfügbaren...

RobertFr 29. Dez 2014

Genau. Gut festgestellt.

RobertFr 29. Dez 2014

Das ist ja mal eine ganz neue Sichtweise. Du hast gar keine Ahnung von C++, oder...

Cerdo 28. Dez 2014

Du Fuchs ;-)



Anzeige

Stellenmarkt
  1. Daimler AG, Stuttgart
  2. Dürr Systems AG, Bietigheim-Bissingen
  3. Sparda-Datenverarbeitung eG, Nürnberg
  4. ORBIT Gesellschaft für Applikations- und Informationssysteme mbH, Darmstadt


Anzeige
Blu-ray-Angebote
  1. 12,99€
  2. (u. a. Apollo 13, Insidious, Horns, King Kong, E.T. The Untouchables, Der Sternwanderer)
  3. 17,97€

Folgen Sie uns
       

Anzeige
Whitepaper
  1. Sicherheitskonzeption für das App-getriebene Geschäft
  2. Mehr dazu im aktuellen Whitepaper von IBM
  3. Wichtige Anwendungen von automatisierter Inventarisierung


  1. Hololens

    Microsoft holoportiert Leute aus dem Auto ins Büro

  2. Star Wars

    Todesstern kostet 6,25 Quadrilliarden britische Pfund am Tag

  3. NSA-Ausschuss

    Wikileaks könnte Bundestagsquelle enttarnt haben

  4. Transparenzverordnung

    Angaben-Wirrwarr statt einer ehrlichen Datenratenangabe

  5. Urteil zu Sofortüberweisung

    OLG empfiehlt Verbrauchern Einkauf im Ladengeschäft

  6. Hearthstone

    Blizzard schickt Spieler in die Straßen von Gadgetzan

  7. Jolla

    Sailfish OS in Russland als Referenzmodell für andere Länder

  8. Router-Schwachstellen

    100.000 Kunden in Großbritannien von Störungen betroffen

  9. Rule 41

    Das FBI darf jetzt weltweit hacken

  10. Breath of the Wild

    Spekulationen über spielbare Zelda



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
Udacity: Selbstfahrendes Auto selbst programmieren
Udacity
Selbstfahrendes Auto selbst programmieren
  1. Strategiepapier EU fordert europaweite Standards für vernetzte Autos
  2. Autonomes Fahren Comma One veröffentlicht Baupläne für Geohot-Nachrüstsatz
  3. Autonomes Fahren Intel baut Prozessoren für Delphi und Mobileye

Quake (1996): Urknall für Mouselook, Mods und moderne 3D-Grafik
Quake (1996)
Urknall für Mouselook, Mods und moderne 3D-Grafik
  1. Künstliche Intelligenz Doom geht in Deckung

Oneplus 3T im Test: Schneller, ausdauernder und immer noch günstig
Oneplus 3T im Test
Schneller, ausdauernder und immer noch günstig
  1. Smartphone Oneplus 3T mit 128 GByte wird nicht zu Weihnachten geliefert
  2. Android-Smartphone Oneplus Three wird nach fünf Monaten eingestellt
  3. Oneplus 3T Oneplus bringt Three mit besserem Akku und SoC

  1. Re: 200.000 Pfund für Essen?

    Analysator | 03:21

  2. Re: Dat Bildunterschrift...

    nf1n1ty | 02:44

  3. Das Problem bei der NSA-Affäre ist, dass nicht...

    fb_partofmilitc... | 02:30

  4. Re: Einheiten richtig umrechnen du musst

    masel99 | 02:17

  5. Re: P2W

    corruption | 02:12


  1. 18:27

  2. 18:01

  3. 17:46

  4. 17:19

  5. 16:37

  6. 16:03

  7. 15:34

  8. 15:08


  1. Themen
  2. A
  3. B
  4. C
  5. D
  6. E
  7. F
  8. G
  9. H
  10. I
  11. J
  12. K
  13. L
  14. M
  15. N
  16. O
  17. P
  18. Q
  19. R
  20. S
  21. T
  22. U
  23. V
  24. W
  25. X
  26. Y
  27. Z
  28. #
 
    •  / 
    Zum Artikel