Wenn Wissen plötzlich $ 19.00 kostet Marc Ruef | 08.01.2007 Zunehmend werden Quelltext-Analysen zu einem wichtigen Instrument. Bei allen Audit-Projekten dränge ich darauf, dass ich früher oder später Einsicht in den Quelltext der jeweiligen Applikationen halten kann. Zusammen mit einer Live-Analyse, wie sie halt mit Werkzeugen wie nmap oder Netcat durchgeführt werden, kann so ein sehr gutes Gesamtbild erarbeitet werden. Durch die Betrachtungen auf allen Ebenen lassen sich die Zusammenhänge ausmachen und damit selbst in den entlegendsten Winkeln eines Produkts etwaige Mängel feststellen. Statische Analysen dieser Art sind über die Jahre ein bisschen ein Hobby von mir geworden. Als ich zu Beginn des Jahres 2004 darüber nachdachte, ob und inwiefern ich meine damals statische HTML-Webseite auf dynamisches PHP übertragen konnte, evaluierte ich rund ein Jahr lang die bekannten Content Management Systeme (CMS). Dabei habe ich sowohl die Funktionalität in Bezug auf Administration und Nutzung, als auch die interne Struktur des Quelltextes bezüglich Sicherheit analysiert. Eine Vielzahl von PHP-Codezeilen habe ich durchforstet, um anhand der Iterationen und MySQL-Abfragen ein Gefühl dafür zu bekommen, wie methodisch und zuverlässig die jeweiligen Entwickler vorgingen. Ganz unterschiedliche Resultate sind dabei gefunden worden. Da gab es grössere Projekte, bei denen scheinbar UNION-Statements in SQL-Zugriffen verpönt waren. Stattdessen setzte mal lieber auf zweifache SELECT-Zugriffe, die in Bezug auf Performance als Todsünde betrachtet werden müssen. Andere Projekte verzichteten auf eine zentralisierte Eingabeüberprüfung und müssen deshalb alle paar Monate eine neue Cross Site Scripting-Schwachstelle beheben. Bei professionellen Quelltext-Analysen gehe ich sehr systematisch vor. Dabei orientiere ich mich an klassischen Techniken aus den Bereichen Developement und Engineering. Die Fehler können dabei grob in drei Klassen unterteil werden. Zum einen weisen gewisse Sprachen unsichere bzw. ungeschützte Funktionen auf. Gerade Pufferüberlauf-Schwachstellen, wie sie im C-Umfeld immerwieder durch Funktionen wie gets() oder strcpy() erzeugt werden, fallen einem schnell ins Auge. Automatisierte Tools zur Überprüfung gibt es in diesem Bereich wie Sand am Meer. Und notfalls kann man sich mit dem grep-Kommando schnell einen Überblick verschaffen. Die zweite Klasse betrifft unsichere Programmabläufe und logische Konstrukte. Ein klassisches Beispiel hierzu definiert sich durch Race Conditions. Die fehlende oder fehlerhafte Synchronisation von Prozessen und Funktionen kann in diesem Fall dazu führen, dass sich das Verhalten oder das Resultat eines Ablaufs beeinflussen lässt. Solche Fehler zu erkennen ist nicht einfach und erfordert ein hohes Mass an Erfahrung. Die dritte Klasse definiert sich in der sogenannten Eingabeungültigkeit. Ein Benutzer kann durch fehlerhafte und damit unerwartete Eingaben erweiterten Einfluss auf die Programmabarbeitung ausüben. OS Command Injection und Code Injection (z.B. SQL-Injection) sind typische Beispiele hierfür. Ein Grossteil der populären Angriffe nutzt eine Programmierschwäche auf dieser Ebene aus. Eines Tages sollte ich eine in Java geschriebene Banking-Applikation überprüfen. Obschon ich zwischendurch ein bisschen mit der ursprünglich von Sun Microsystems ins Leben gerufenen Sprache arbeite, wollte ich mich vor dem Anlaufen des Projekts auf den neuesten Stand bringen. Durch das Lesen neuer und mir unbekannter Titel (Fachartikel und Bücher) sollte mein Wissen aufgefrischt und ich auf das Projekt eingestimmt werden. Leider fand ich im Internet nur wenige gute Beiträge. Über die Suche bei Google bin ich jedoch über einen Fachartikel mit dem Titel Statically Scanning Java Code: Finding Security Vulnerabilities (http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/so/&toc=comp/mags/so/2000/05/s5toc.xml&DOI=10.1109/52.877869) gestossen. Er wurde mitunter von John Viega und Gary McGraw verfasst, von denen ich schon einiges gelesen habe. Als ich mir diese Abschrift herunterladen wollte, war ich jedoch ein bisschen erstaunt. Tatsächlich verlangte man hier von mir, dass ich $ 19.00 für den Kauf ausgeben sollte. Ich will ja nicht unhöflich sein, aber der Artikel nahm in IEEE Software, vol. 17, no. 5 (Sept/Oct 2000) gerade mal sechs Seiten ein. Für sechs Seiten soll ich $ 19.00 bezahlen? Ich weiss gar nichts über den Beitrag, abgesehen vom kurzen Abstract, das zu lesen mich wenigstens nichts gekostet hat: "Developers and users require some degree of assurance in their applications' security vulnerabilities. The authors have designed a prototype tool, Jslint, to help programmers automatically use existing security knowledge." Irgendwie machte mich das traurig. Für das Beziehen einer elektronischen Kopie eines läppischen Artikels soll ich so viel bezahlen? Wo bleibt die wissenschaftliche Kollegialität, die Offenherzigkeit und das kleine bisschen Altruismus, für das manche Leute kämpfen? Dies blieb auf der Strecke, denn schliesslich kann man mit sechs Seiten nun scheinbar $ 19.00 verdienen. Mein nächstes Buch (http://www.cul.de/net.html#vorschau) wird rund 1'000 Seiten umfassen. Kann ich nun deshalb $ 3166.70 verlangen? Ich sah also vom Kauf ab. Wenigstens eine Entscheidung, die ich in der freien Marktwirtschaft aus "freien Stücken" treffen konnte. Ob dies die richtige Entscheidung war, werde ich wohl nie erfahren. Denn ich glaube kaum, dass irgendjemand in meinem Umfeld bereit wäre, die $ 19.00 auf den Tisch zu legen und mir dann vom wertvollen Artikel zu berichten. Wieviel Geld würde ich wohl verdienen, würde ich jeden Download (http://www.computec.ch/download.php) auf der Webseite in gleicher Weise in Rechnung stellen...?