Dritt-Entwickler können effizient auf die Suche nach kritischen Bugs gehen
Drei Gratis-Tools: Microsoft unterstützt IT-Sicherheitsexperten
Vom Saulus zum Paulus: War Microsoft früher noch die Sicherheitsgefahr Nummer 1, haben sich die Redmonder inzwischen in Entwicklerkreisen den Ruf erarbeitet, erheblich weniger anfälligen Sourcecode zu schreiben. Jetzt gibt der Konzern drei Gratis-Tools frei, mit denen auch andere Entwickler effizient auf die Suche nach kritischen Bugs gehen können.
Im Rahmen der Hacker-Konferenz CanSecWest kündigte Microsoft an, drei Anwendungen zum Download
anzubieten, die allen Programmieren helfen sollen, ihren Sourcecode von sicherheitsrelevanten Bugs
zu befreien. Alle drei Tools entstammen Microsofts Security Science Team, ein kleiner Trupp von
Entwicklern, die den eigentlichen Bugjägern in Redmond mit neuen Tools das Leben erleichtern. Haben
sich die Anwendungen des Teams in der Praxis bewährt, werden sie mit in den
Security Development Lifecycle
(SDL) aufgenommen.
Damit gehören die Tools dann zum Pflichtprogramm aller Microsoft-Entwickler, da der SDL
inzwischen Grundlage für alle Projekte des Konzerns ist. SDL verankert sicherheitsrelevante
Prüfungen und Arbeitsschritte fest im Entwicklungsprozess eines jeden Microsoft-Softwareprodukts
und wird unter anderem durch Tools ständig weiter entwickelt.
Dass dies genau der richtige Ansatz ist, bestätigt der Hacker Dan Kaminsky: "Das nachträgliche
Patchen ist die ineffizienteste Methode sind, um Software abzusichern." Denn die Kosten für einen
Patch seien um ein Vielfaches größer im Vergleich zum finanziellen Aufwand, der nötig gewesen wäre,
um den Bug schon im Vorfeld zu verhindern. Kaminsky: "Sicherere Systeme sind nur machbar, wenn
Sicherheit fester Bestandteil des Entwicklungsprozesses ist. Dann lässt sich der mit großem Aufwand
verbundene Prozess der Entwicklung und des Testens von Sicherheit-Updates vermeiden."
Wurm
spricht Deutsch: Conficker-Virus befällt viele deutsche Firmenrechner
Neue
Variante von Conficker ist noch tückischer
Conficker:
Microsoft setzt 250.000 Dollar Kopfgeld aus
Regelmäßige
Sicherung von Systemen bietet mehr Sicherheit vor Bedrohungen wie Conficker
F-Secure:
70 Prozent schätzen die Gefahren bei der Internet-Nutzung falsch ein
Aus diesem Grund bewertet Kaminsky auch den SDL als überaus positiv und wichtig: Laut Kaminsky
ist der Grund für unsicheren Code zumeist, dass der Entwickler sich vieler Sicherheitsprobleme
nicht bewusst ist. SDL versorgt Programmierer mit dem notwendigen Wissen, so dass sie auch ohne
umfassende Sicherheitsexpertise sicheren Code schreiben können.
Nach Einschätzung des renommierten Hacking-Experten Kaminsky – er ist seit der Entdeckung des
fundamentalen Sicherheitslochs in DNS sicherlich einer der bekanntesten Hacker überhaupt – 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 verändert und 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 Hacker tun, wenn die Systeme millionenfach eingesetzt werden.
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. Und 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."
Die Tools im einzelnen:
1. Das !exploitable (sprich: Bang exploitable) Crash Analyzer genannte Windbg-Plugin
beispielsweise durchsucht 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
Crash-Daten nach auffälligen, bekannten Mustern, die auf Schwachstellen hindeuten, die sich
möglicherweise von Crackern angreifen lassen.
Laut Jason Shirk, dem Entwickler von !exploitable, hat sein Tool eine große Anzahl von solchen
Mustern im Gepäck, so dass es blitzschnell Übereinstimmungen zwischen Crash-Daten 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 Lücke. Der Entwickler muss also selbst
kein Sicherheitsfachmann sein, um das Problem richtig einzuschätzen. Außerdem hilft es den oftmals
jungen Programmieren, die zum Testen abgestellt werden, den erfahreneren Kollegen die Relevanz des
Bugs zu verdeutlichen.
Wird ein Bug als "wahrscheinlich ausbeutbar" eingeordnet, 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. Shirk sagt: "Ein solcher Hinweis sollte für
jeden Programmierer eine grellrote Warnlampe sein. Ganz egal, ob er hier bei uns arbeitet, oder bei
einem anderen Unternehmen."
Shirks Programm macht umfangreiches Fuzztesting erst möglich. Er erzählt, dass beim Testen einer
Anwendung mit vier verschiedenen Fuzzern insgesamt 57 verschiedene Abstürze provoziert wurden. "Für
einen Menschen ist es unmöglich, all diese Crash-Dumps in vertretbarer Zeit nach
sicherheitsrelevanten Informationen zu durchforsten", sagt Shirk. !exploitable erledigt das binnen
weniger Minuten.
2. Die zweite Neuerung kommt allen Visual-Studio-Anwendern zugute: In Visual Studio 2010 findet
sich das GS enhancement. Das /GS-Flag ist wichtig, um beim Kompilieren eventuelle Buffer Overflows
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.
3. Drittens stellt Microsoft noch die Anwendung High Signal-to-Noise Vulnerability Detection zur
Verfügung. Auch dieses Tool dient der Effizienzsteigerung: Programme wie PreFast, die zur
statischen Codeanalyse eingesetzt werden, erzeugen in der Praxis notgedrungen sehr viele
False-Positive-Meldungen. So warfen drei Tools nach der Analyse von knapp drei Millionen Codezeilen
insgesamt 175.000 Warnmeldungen aus – unmöglich, all diesen Hinweisen nach zu gehen.
High Signal-to-Noise Vulnerability Detection hilft nun 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 Prozent. Nach Analyse durch den
Entwickler stellte sich heraus, dass eine Warnmeldung in der Tat berechtigt war.
Uli Ries/CZ
Lesen Sie mehr zum Thema
