Software-Sicherheit – Teil 2

Bugs mit statischer und dynamischer Code-Analyse entdecken

16.03.2011 | Autor / Redakteur: Marcell Dietl / Stephan Augsten

Fehler vs. Features: Unternehmen sollten Open-Source-Quellcode auf mögliche Hintertüren und Schwachstellen testen.

Regierungen und Unternehmen setzen verstärkt auf Open-Source-Software, da das Mehr-Augen-Prinzip einen Sicherheitszuwachs verspricht. Doch blindes Vertrauen stellt eine Gefahr für die eigenen Daten dar. SearchSecurity.de stellt mehrere Ansätze zur Quellcode-Analyse und Risiko-Minimierung vor.

Der OpenBSD-Gründer Theo de Raadt erhielt Ende 2010 eine E-Mail, die in der Öffentlichkeit für große Besorgnis sorgte. Darin wurde vor einer möglichen Hintertür in OpenBSD gewarnt, Auftraggeber sei das FBI gewesen. Autor der E-Mail war ein ehemaliger Berater der Bundesbehörde, dessen Verschwiegenheitsvereinbarung nach zehn Jahren ausgelaufen war.

Prompt durchgeführte Code-Reviews brachten zwar keine Backdoor zum Vorschein, doch ein fader Beigeschmack bleibt. Zudem war es Unbekannten nur wenige Tage zuvor gelungen, eine – recht plumpe – Lücke in den Code des quelloffenen FTP-Servers ProFTPD zu pflanzen.

Fälle dieser Art zeigen die Problematik, die der Einsatz fremder Software mit sich bringt. Und speziell in der Open-Source-Gemeinde ist es üblich, den Code anderer Projekte in das eigene zu integrieren – inklusive aller Bugs und möglicher Hintertüren.

Besonders in kritischen Bereichen, in denen der Zugang zu sensiblen Daten möglich ist, sollte blindes Vertrauen in fremde Programmierer durch strikte Kontrollen der eigenen Experten ersetzt werden. Nur so kann auch von einem wirklichen Zugewinn an Sicherheit gesprochen werden.

Lexikalische und semantische Code-Audits

Die mit Abstand gröbste Methode, Software-Fehler zu finden, stellt die bloße Suche nach bestimmten Schlüsselwörtern dar. So ließe sich etwa mit dem Linux-Kommando „grep“ jede Codezeile ausgeben, in der die für Buffer Overflows berüchtigte strcpy()-Funktion auftaucht.

Auf diese rein lexikalische Taktik setzt zum Beispiel das in Python geschriebene Tool „flawfinder“ von David A. Wheeler. Leider birgt diese Vorgehensweise zwei große Nachteile:

  • Wird eine als unsicher eingestufte Funktion vom Programmierer wider Erwarten korrekt implementiert, schlägt das Tool häufig dennoch Alarm. Dieser Irrtum wird auch als False Positive bezeichnet. Gleichzeitig übersieht die bloße Suche nach Schlüsselwörtern viele komplexere Fehler – False Negatives genannt.
  • Um die Menge an False Positives und Negatives zu reduzieren, wurden semantische Source Code Analyzer entwickelt. Diese bewerten nicht nur ob eine Funktion genutzt wird, sondern auch wie und in welchem Zusammenhang. Das von David Evans programmierte „Splint“ nutzt dazu spezielle Annotations, durch die Vorbedingungen und Beschränkungen für Funktionen gesetzt werden können. So muss etwa der Zielpuffer einer Kopieroperation wie strcpy() stets größer oder gleich dem Quellpuffer sein, um Buffer Overflows zu vermeiden.

Inhalt

Inhalt des Artikels:

»1 »2 »3 nächste Seite

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)



Spamschutz 

Bitte geben Sie das Resultat dieser Rechenaufgabe (Addition) ein:
Kommentar abschicken

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2050293)