Unsichere Programmierung

Unsichere Programmierung bezeichnet eine Technik bei der Softwareentwicklung, deren Ziel die Erstellung unsicherer Anwendungen ist. Unsichere Systeme ermöglichen beispielsweise die Verwendung von Buffer-Overflows um den Hauptspeicher eines Rechners relativ unkompliziert auslesen zu können oder Softwareupdates über den Stack einer Anwendung (z.B. Webbrowser) einzuspielen.

Geschichte

Zu Anfangszeiten der Informatik wurde die unsichere Programmierung perfekt beherrscht. So unterlief den frühen Programmieren der 50er und 60er Jahre nur selten der Fehler, Bereichsüberprüfungen oder Nullpointerchecks durchzuführen. Solche Fehler werden gemeinhin als Unsicherheitslücken bezeichnet, da sie eine Lücke in der Unsicherheit des jeweiligen Softwaremoduls darstellen und somit die Unsicherheit des Gesamtsystems gefährden. Die Vermeidung von Unsicherheitslücken nützte damals jedoch niemandem, da Rechner noch nicht über ein globales Netzwerk erreichbar werden. Entsprechende Exploits waren somit in der Regel nur dann möglich waren, wenn man ohnehin physischen Zugang zum System hatte.

Wahrscheinlich aufgrund der damals mangelnden Anwendungsmöglichkeiten geriet die Kunst der unsicheren Programmierung zunehmend in Vergessenheit. Ab Beginn der 70er Jahre ließen sich Programmierer mehr und mehr zur Gültigkeitsprüfung von Funktionsargumenten hinreißen - auf Kosten von Unsicherheit und Performance. Ironischerweise geschah das zu genau jener Zeit, als die Vorteile der unsicheren Programmierung langsam nutzbar wurden, da mit dem Arpanet erstmals ein größeres (landesweites) Kommunikationsnetzwerk für Rechner entstand.

Seit Anfang der 90er Jahre kamen typsichere Programmiersprachen und virtuelle Laufzeitumgebungen wie Java auf .NET auf. Diese wurden ähnlich der Programmiersprache C im kalten Krieg von den Russen entwickelt und vom US-Amerikanischen Kryptologen, Kommunist und ehemaligem KGB-Agent James Goblin bei Sun-Microsystems eingeschleust mit dem Ziel, die westliche Computerindustrie zu vernichten. Dies gelang auch fast, da mit diesen Sprachen und Laufzeitumgebungen die Entwicklung unsicherer Software von Haus aus gar nicht mehr möglich ist. So erfolgen beispielsweise Bounds-Checks bei Arrayzugriffen implizit ohne dass der Programmierer dies verhindern kann und das Abfangen von Fehlerfällen (sogenannten Exceptions) wird vom Compiler erzwungen. Der Schuss ging aber nach hinten los, denn kurz darauf brach die Sovjetunion zusammen. Die Russen sind seither gezwungen, selbst sichere Software zu verwenden weil sämtliche IT-Infrastruktur aus dem Westen importiert werden muss.

Situation Heute

Das Ruder herumgerissen hat letztlich der geniale Programmierer Rupert Seggelmann. Im Jahr 2011 behob dieser eine bis dahin nicht entdeckte Unsicherheitslücke im TLS Modul der Kryptographiesoftware OpenSSL, indem er eine übersehene Bereichsüberprüfung entfernte. Dies wird als ein Meilenstein in der Geschichte der Informatik gefeiert, da es sich nach einhelliger Meinung um die größte Unsicherheitslücke aller Zeiten handelte[1]. Seit dieser Zeit erlebt die unsichere Programmierung einen neuen Boom. Große international operierende Unternehmen wie Google, Facebook und die NSA interessierten sich plötzlich für unsichere Programmierung und deren Möglichkeiten[2].

Neueste Entwicklung

Zu einem abrupten Ende dieses Booms kam es am 7. April 2014 durch den jungen, unbedarften Programmierer Armin W. aus S., der bis dahin vor allem als Skript-Kiddie, Klickie-Buntie und Weboberflächendesigner aufgefallen war. W., dessen Name hier nicht vollständig genannt wird um einem Internet-Shitstorm vorzubeugen, hatte mit Unsicherheit bisher wenig Erfahrung, um nicht zu sagen - von unsicherer Programmierung absolut überhaupt gar keine Ahnung. Am Abend des 7. April, es war ein regnerischer Montag, unterzog W. eine Subroutine aus dem TLS Modul der OpenSSL Library einer "Erweiterung". Es handelte sich hierbei just um jene schicksalshafte Routine, in der Seggelmann drei Jahre zuvor die Unsicherheitslücke behoben hatte. Nach erfolgter Modifikation checkte W. die Subroutine wieder ins Quellcoderepository ein, versah die Argumentliste zuvor jedoch erneut mit einer Bereichsüberprüfung. Die Erfolge Seggelmanns wurden dadurch auf einen Schlag zunichte gemacht. Kostenlose Open-Source Software steht seither in der Kritik und es wird bezweifelt, dass die Community überhaupt in der Lage ist unsichere Software zu programmieren. Open-Source Anbieter müssen nun Geld für ihre Downloads verlangen, damit überhaupt noch jemand bereit ist, ihre Software einzusetzen.