Open Source im professionellen Einsatz
Linux-Magazin 08/2014
© alphaspirit, 123RF

© alphaspirit, 123RF

Sicherheitsschwächen in Software finden

Auf Fehlersuche

In fast jeder Software stecken Fehler, nicht wenige davon untergraben sogar die Sicherheit. Was können die Entwickler schon bei Beginn dagegen tun? Ein Überblick.

575

Programmierer sind Menschen, und Menschen machen Fehler. Interessanter als diese Binsenweisheit ist allerdings, dass sie offenbar immer wieder die gleichen machen. Das zeigt die Liste der 25 gefährlichsten Softwarefehler [1]. Sie beruht auf der Common Weakness Enumeration (CWE, Liste geläufiger Sicherheitsschwächen) der Non-Profit-Organisation Mitre, die für US-Bundesbehörden die Sicherheit von Programmen untersucht.

Übliche Verdächtige

Wer gegen diese Fehler vorgeht, kann die Sicherheit seiner Software deutlich verbessern, weshalb Mitre auch gleich einen Maßnahmenkatalog anbietet. Unter dem Posten M1 der so genannten Monster Mitigations findet sich die altbekannte Empfehlung, alle Eingaben zu kontrollieren. Dazu gehören auch Angaben zur Länge des Inputs, die Open SSL in Heartbeat zum Verhängnis wurden. Die CWE und ihre Begleitmaterialien gehören zur Kategorie Aufklärung, die eine der Maßnahmen für bessere Softwaresicherheit darstellt. Sie machen Entwickler mit häufigen Fehlerarten wie Buffer Overflow, SQL-Injection und Link Following vertraut, um sie für das Auftreten in ihrem eigenen Code zu sensibilisieren.

In diese Kerbe schlagen auch das Secure-Programming-Howto von David Wheeler [2] und die Linux-Magazin-Reihe "Sicheres Programmieren für Administratoren" von Dominik Vogt [3], die beide kostenlos online zugänglich sind.

Allerdings werden Software-Entwickler für das bezahlt, was ihre Programme tun, und nicht dafür, welche Sicherheitslücken sie vermeiden. Auch in Open-Source-Projekten, ob kommerziell oder ideell motiviert, stehen die erwünschten Features im Mittelpunkt. Daher trage auch Test Driven Development (TDD) wenig zur Sicherheit bei, kritisiert David Wheeler in einem Aufsatz, den er unter dem Eindruck von Heartbleed verfasst hat [4]: Sie denken vornehmlich an den so genannten Happy Path, den Programmablauf bei ordnungsgemäßer Benutzung des Programms. Sicherheitslecks dagegen treten auf, wenn der Anwender Software gegen den Strich bürstet und beispielsweise ungewöhnliche Eingaben macht. Daher fordert Wheeler negatives Testing, das sich auf ungültigen Input und Grenzfälle spezialisiert.

Fuzzing

Eine Sonderform beim negativen Testing, die sich leicht automatisieren lässt, ist das Fuzzing [5], das erstmals 1988 der Informatiker Barton Miller beschrieben hat. Hierbei bombardiert man die zu testende Software mit zufällig generierten Eingaben oder Mutationen von Eingabe- und Konfigurationsdateien – in der Hoffnung, auf eine bestehende Sicherheitsschwäche zu treffen. Im einfachsten Fall führt das zum Absturz des Programms.

Verfeinerte Varianten des Fuzz Testing verwenden einen Address Checker. Er prüft, ob sich das Programm durch die Eingaben dazu bringen lässt, über Speicherbereiche hinaus zu schreiben (Buffer Overflow) oder zu lesen (Out-of-Bounds Read). Zu diesem Zweck dient beispielsweise das Tool Address Sanitizer [6], das Speicherfehler in C- und C++-Programmen aufspürt. Es steht als Option in GCC ab Version 4.8 und in Clang ab 3.1 zur Verfügung. Zu seinen Anwendern zählen die Entwickler der Browser Chromium und Firefox. Address Sanitizer instrumentiert den Code, was zu Performance-Einbußen führt, die aber für Testzwecke akzeptabel sind.

Fuzzing kommt unter anderem bei der Arbeit am Linux-Kernel zum Einsatz. Das Tool Trinity [7] des Red-Hat-Entwicklers Dave Jones beackert Systemaufrufe und hat schon Dutzende Schwächen im Kernel offenbart, von denen allerdings noch nicht alle behoben sind.

Probleme mit der Speicherverwaltung findet auch die freie Werkzeugsammlung Valgrind [8]. Das einfache C-Programm in Listing 1 greift auf nicht allozierten Heap-Speicher zu. Wer es kompiliert und das Executable mit »valgrind ./a.out« aufruft, bei dem bemängelt das Analyseprogramm den Fehler (Abbildung 1).

Listing 1

Speicherfehler

01 #include <stdlib.h>
02
03 int main(void)
04 {
05     char *x = malloc(10);
06     x[10] = 'a';
07     return 0;
08 }
Abbildung 1: Valgrind bemängelt den Fehler in der Speicherverwaltung im kompilierten Programm aus Listing 1.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 3 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

comments powered by Disqus

Ausgabe 11/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.