Microsoft öffnet die Werkzeugkiste
Von Uli Ries
War Microsoft die längste Zeit noch die Quelle alles unsicheren Codes, haben sich die Redmonder inzwischen den Ruf erarbeitet, erheblich weniger anfälligen Sourcecode zu schreiben. Jetzt gibt der Konzern zahlreiche Gratistools frei, mit denen auch andere Entwickler sicherere Anwendungen schreiben können.
Im Rahmen seines Security Development Lifecycles (SDL) hat Microsoft nach und nach Tools zum Download bereitgestellt, mit denen Programmierer das gesammelte Wissen des SDL in ihre Softwareentwicklungsumgebung integrieren können sollen. SDL ist der ehemals rein intern genutzte Microsoft-Prozess, um möglichst sichere und fehlerfreie Software zu programmieren. SDL wurde 2004 ein notwendiger Bestandteil des Entwicklungsprozesses sämtlicher Microsoft-Anwendungen und -Betriebssysteme.
Vorlage statt Checklisten
Der Softwarekonzern ließ Entwickler außerhalb von Microsoft schon seit längerem am SDL teilhaben. Bislang veröffentlichte das Unternehmen die Vorgaben und Ratschläge, die das Grundgerüst des SDL bilden, aber nur in Form einer rein schriftlichen Dokumentation. Für Programmierer war es so äußerst mühselig, den eigenen Entwicklungsprozess mit SDL in Einklang zu bringen.
Teil 1 zeichnet eine recht erfolgreiche Geschichte nach: von der Trustworthy-Computing-Mail Bill Gates’ bis zu den offenen Threat Modeling Tools für Programmierer. Teil 2 interessiert sich dafür, wie kooperative Hacker den MS-Code austesten und wie die Ergebnisse per Patch Tuesday in alle Welt gehen. Teil 3 stellt die wichtigsten Hilfsmittel vor, die Microsoft Entwicklern an die Hand gibt, damit sie gefährliche Bugs rechtzeitig identifizieren.
Mit dem so genannten Process Template bietet Microsoft nun erstmals ein Tool, das den kompletten SDL abbildet. Dazu bedient sich Microsoft eines Templates für Visual Studio Team System. Grundlage des Templates ist die aktuelle Version 4.1 des jährlich erneuerten SDL. Laut Microsoft sei das SDL 4.1 gegenüber der Vorgängerversion vor allem um Vorgaben erweitert worden, die bei der Entwicklung von sicheren Online-Anwendungen helfen sollen. Denn Webservices und auch lokale Anwendungen, die ständig oder oft mit dem Internet verbunden sind, brächten spezielle Anforderungen an ein Sicherheitskonzept mit.
Um das vorgestellte Template zu nutzen, müssen die Entwickler ihren Sourcecode mit Microsofts Visual Studio schreiben. Andernfalls hat das Template keinen Nutzen, da es sich nur in Visual Studio Team System einbinden lässt. Microsoft verweist in diesem Zusammenhang aber auf den Vorteil, dass mit Visual Studio Team System vertraute Entwickler auf diese Art extrem einfach nach Anleitung durch das SDL arbeiten könnten.
Einer der Hauptvorteile soll sein, dass selbst Entwickler, die keinerlei Security-Expertise haben, so sicheren Code schreiben können. Ob Microsoft das Template auch an andere Softwareentwicklungsumgebungen anpasst, ist noch unklar. Auszuschließen sei es jedoch nicht, vielmehr machen die Redmonder andere Varianten von den Rückmeldungen aus der Entwicklergemeinde abhängig.
Schwarz auf Weiß
Dieser Beitrag erschien zuerst in unserer Magazinreihe. Einen Überblick mit freien Download-Links zu sämtlichen Einzelheften bekommen Sie online im Pressezentrum des MittelstandsWiki.
Interessierte Entwickler, die ihren eigenen Programmierprozess durch den SDL absichern wollen, können die vorgefertigten, länglichen Checklisten und Ratschläge an ihre jeweiligen Bedürfnisse anpassen und müssen sich somit nicht an Prozessschritten entlanghangeln, die für sie irrelevant sind. Um möglichst klare Zuständigkeiten zu schaffen, kann jede Aufgabe, wie z.B. das Beseitigen eines Bugs im Sourcecode, mit dem Template einer Person oder einem Team zugeordnet werden. Der Status des jeweiligen Projekts soll auf einen Blick ersichtlich sein. Außerdem sollen sich leicht Statistiken und Reports erzeugen lassen, mit denen sich unter anderem die Effektivität von externen, auch Microsoft-fremden Tools zum Aufspüren von Bugs bewerten lassen soll.
Absturzursachen einschätzen
Neben dem SDL-Template hat Microsoft noch drei weitere Anwendungen zum Download bereitgestellt, die allen Programmieren helfen sollen, ihren Sourcecode von sicherheitsrelevanten Bugs zu befreien. So durchsucht das !exploitable Crash Analyzer (sprich: „Bang exploitable“) genannte Windbg-Plugin z.B. vollautomatisch die Dumpfiles, die Windbg nach dem Absturz einer Anwendung erzeugt. Die Erweiterung lässt die Programme nicht selbst abstürzen, sondern sucht in den Crashdaten nach auffälligen, bekannten Mustern, die auf Schwachstellen hindeuten, die sich möglicherweise von Crackern angreifen lassen.
Laut Microsoft hat !exploitable eine große Anzahl von solchen Mustern im Gepäck, so dass es blitzschnell Übereinstimmungen zwischen Crashdaten und der Sammlung von Sicherheitslücken herstellen kann. Versteckt sich ein bekanntermaßen gefährlicher Bug im Code, klassifiziert das Plugin die Lücke je nach Schweregrad. Der Entwickler muss also selbst kein Sicherheitsfachmann sein, um das Problem richtig einzuschätzen. Außerdem gibt es laut Microsoft den oftmals jungen Programmierern, die von Unternehmen zum Testen abgestellt werden, bessere Argumente gegenüber den erfahreneren Kollegen an die Hand, um die Relevanz des gefundenen Bugs zu verdeutlichen.
Ordnet das Programm einen Bug als „wahrscheinlich ausbeutbar“ ein, heißt das für alle Microsoft-Programmierer, dass der Fehler zwingend behoben werden muss, bevor der Code ins hausinterne Sourcecode-System geladen werden kann. Demnach sollte ein solcher Hinweis für jeden Programmierer – egal, ob er für Microsoft arbeitet oder bei einem anderen Unternehmen Software entwickelt – eine grellrote Warnlampe sein. Außerdem macht !exploitable Microsoft zufolge umfangreiches Fuzztesting erst möglich. So wurden bei internen Tests einer Anwendung mit vier verschiedenen Fuzzern insgesamt 57 verschiedene Abstürze provoziert. Ein Programmierer könne all diese Crash-Dumps unmöglich in vertretbarer Zeit nach sicherheitsrelevanten Informationen durchforsten. Das Tool schafft dies binnen weniger Minuten.
Stabiler kompilieren
Ein weiteres von Microsoft zur Verfügung gestelltes Hilfsmittel kommt allen Visual-Studio-Anwendern zugute: In Visual Studio 2010 findet sich das „GS enhancement“. Das schon seit längerem genutzte /GS-Flag ist wichtig, um beim Kompilieren eventuelle Schwachstellen, die später als Einfallstor per Buffer Overflow missbraucht werden können, im Sourcecode zu entdecken. Durch die Verbesserung sollen einerseits noch mehr solcher Schwächen entdeckt werden (unter anderem String Buffers und Integer Array Buffers). Zum anderen sollen die solchermaßen kompilierten Anwendungen später in der Praxis erheblich flotter laufen als es Programme tun, die mit älteren Versionen und gesetztem /GS-Flag kompiliert wurden.
Aufs Entscheidende eindampfen
Ebenfalls Teil des hauseigenen SDL-Prozesses könnte Microsofts Anwendung names High Signal-to-Noise Vulnerability Detection werden. Auch dieses Tool dient der Effizienzsteigerung: Programme wie PreFast, die zur statischen Codeanalyse eingesetzt werden, erzeugen in der Praxis notgedrungen sehr viele falsch-positive Meldungen. So warfen laut Microsoft bei internen Tests drei Tools nach der Analyse von knapp drei Millionen Codezeilen insgesamt 175.000 Warnmeldungen aus – unmöglich, all diesen Hinweisen nachzugehen.
High Signal-to-Noise Vulnerability Detection hilft dem Entwickler, in dem es identische Hinweise, die von allen eingesetzten Analysetools ausgegeben wurden, auf jeweils nur eine Meldung reduziert. So blieben im genannten Beispiel lediglich zwei verschiedene relevante Hinweise auf möglicherweise problematischen Code übrig – eine Reduktion um 99,99 %. (Nach Analyse durch den Entwickler stellte sich heraus, dass eine Warnmeldung in der Tat berechtigt war.)
Geschrieben wurden die drei letztgenannten Tools von Microsofts Security Science Team, einem kleinen Trupp von Entwicklern, die den eigentlichen Bugjägern in Redmond mit neuen Tools das Leben erleichtern. Haben sich die Anwendungen des Security Science Teams in der Praxis bewährt, werden sie mit in den SDL aufgenommen. Damit gehören sie dann zum Pflichtprogramm aller Microsoft-Entwickler, da der SDL inzwischen Grundlage für alle Projekte des Konzerns ist.
Sauber von Anfang an
Wie relevant das Entwickeln sicherer Anwendungen ist, verdeutlichen Microsoft-Sprecher gerne anhand von Statistiken. So entfielen inzwischen nur noch knapp 10 % aller aufgetauchten Exploits auf das Betriebssystem. Die übrigen 90 % tauchten laut Microsoft-eigener Erhebungen in Anwendungen und Webbrowsern auf.
Wie wirksam der SDL ist, bescheinigt der Hacker Dan Kaminsky. Kaminsky erklärte in kleiner Runde vor Journalisten, dass sicherere Systeme nur machbar sind, wenn Sicherheit fester Bestandteil des Entwicklungsprozesses ist. Dann lässt sich der mit großem Aufwand verbundene Prozess der Entwicklung und des Testens von Sicherheitsupdates vermeiden. Aus diesem Grund bewertet Dan Kaminsky auch den SDL als überaus positiv und wichtig: Laut Kaminsky ist der Grund für unsicheren Code zumeist, dass der Entwickler sich vieler Probleme gar nicht bewusst ist. SDL und insbesondere das bereits erwähnte Template für Visual Studio Team System versorgt Programmierer mit dem notwendigen Wissen, so dass sie auch ohne umfassende Sicherheitsexpertise sicheren Code schreiben können.
Die Bemühungen des Softwarekonzerns, möglichst sichere Betriebssysteme zu liefern, haben demnach dazu geführt, dass sich Cracker mit den vergleichsweise schlecht gesicherten Anwendungen neuen Zielen zuwandten. Denn laut Microsoft unterziehen 70 % aller Anwendungsentwickler ihre Programme keinerlei Sicherheitstests, bevor sie sie veröffentlichen. Sicherheitslöcher werden in diesen Fällen also ausschließlich nach Auslieferung der Programme gestopft.
Gleichzeitig hat die US-Behörde NIST (National Institute of Standards and Technology) ermittelt, dass es 30-mal günstiger ist, Sicherheitsprobleme bereits während der Designphase zu erkennen und zu beseitigen, als wenn dies nach Fertigstellung des Produkts passiert.
Fazit: Finden ist Macht
Laut Kaminsky hat sich die Qualität des Codes, der bei Microsoft seit Einführung des SDL in den letzten sechs Jahren geschrieben wurde, im Vergleich zur Prä-SDL-Ära um Welten verbessert. Kaminsky weiß, wovon er spricht: Er gehört zum Kreis der Whitehat-Hacker, die – im Auftrag von Microsoft – während der Entwicklung der Betriebssysteme den Sourcecode von Systemen wie Windows Vista, Windows 7 oder Server 2008 analysieren.
Das Ziel der externen Hacker: Möglichst viele Bugs zu finden, bevor es bösartige Kollegen tun, wenn die Systeme millionenfach eingesetzt werden. Kaminsky wurde zum ersten Mal um Hilfe gebeten, als Microsoft gerade Windows Vista und das Service Pack 2 für Windows XP entwickelte. In beiden Systemen fand sich laut Kaminsky noch sehr viel Code, der Jahre vor Einführung des SDL geschrieben wurde und entsprechend unsicher war. Der Hacker kann sich demnach auf eigene Erfahrungen verlassen, wenn er die unterschiedlichen Code-Jahrgänge miteinander vergleicht.
Kaminsky sieht im SDL ein probates Mittel, sicherere Anwendungen zu entwickeln und rät allen Softwareunternehmen, sich SDL genauer anzuschauen. Ohne Sicherheitsbewusstsein werden die Anwendungen sonst allzu schnell zum Einfallstor für bösartige Hacker. Die sind laut Kaminsky inzwischen ganz anderes motiviert als noch vor wenigen Jahren: „Die Angreifer haben sich gewandelt. Es sind nicht mehr länger Kids. Heute werden wir von Menschen angegriffen, sie selbst Kids haben – und die diese ernähren wollen.“
Uli Ries ist freier Journalist und Autor mit abgeschlossene journalistischer Ausbildung und langjähriger Erfahrung (u.a. bei CHIP, PC Professionell und www.notebookjournal.de). Seine Spezialgebiete sind Mobilität, IT-Sicherheit und Kommunikation – zu diesen Themen tritt er immer wieder auch als Moderator und Fachreferent auf.
Kontakt via Xing
