Letzte Woche endete der Text folgendermaßen: "Warten wir erst mal ab, was Microsoft am Dienstag an Neuem zur Statistik hinzufügt. Und was dann die bösen Buben am Mittwoch an neuen Schwachstellen aus ihren schwarzen Hüten zaubern." auf. Diese Woche kann er passend mit "Es gibt eine neue Schwachstelle in Microsoft Office, genauer: In Powerpoint." anfangen. Wem das bekannt vorkommt: Ähnlich sah es auch am 14. August aus. Und auch am 18. September war es nicht viel anders, nur habe ich da auf die Wiederholung der Vorhersage verzichtet. Das erinnert langsam aber sicher an 'Dinner for one': 'Same procedure as last month'.

Mit regelmäßigen neuen Schwachstellen und den dazugehörigen Schadprogrammen werden wir wohl noch einige Zeit leben müssen. Wenn nicht sogar für immer. Denn auch Ansätze wie Microsofts PatchGuard zur Verhinderung von Änderungen am Kernel werden früher oder später ausgetrickst werden oder auch selbst Schwachstellen enthalten. Was sich ändern kann, ist Microsofts Strategie des Patchdays. Der gehört auf den Schutthaufen der Geschichte. Aber auch das habe ich ja schon Anfang August geschrieben.

Gesucht, gefunden...
Genug der "ollen Kamellen", kommen wir zu aktuelleren Entwicklungen. Dass Googles Code Search zu allerlei Experimenten zu gebrauchen ist, hat sich vielleicht schon herumgesprochen. Für diejenigen, für die das neu ist, hier ein paar Links:

• Gadi Evron hat im SecuriTeam-Blog eine Sammlung von Abfragen zusammengestellt
• Ebenfalls beim SecuriTeam-Blog: "Code Auditing with Google"
• Dug Song hat sich Gedanken über die statische Code-Analyse mit Code Search gemacht
• Auch eine erste (noch sehr grobe) Statistik über mögliche Schwachstellen gibt es bereits
• Und zum Schluss eine weitere Sammlung von Suchabfragen beim "Google Source Code Bug Finder"

... oder auch nicht...
Eigentlich wollte ich jetzt schreiben "Da wird es demnächst wohl wieder reichlich Advisories zur 'Remote File Inclusion' in PHP-Skripts geben, bei denen nur nach 'include($' gesucht und danach nichts weiter geprüft wurde". (siehe auch den 'Standpunkt' vom 21. August). Das war vor dem Wochenende. Am Samstag ging es dann schon los. Bisher habe ich 15 ganz oder vollständig falsche Advisories ausgefiltert. Einige dieser besonders typischen Nicht-Schwachstellen will ich hier kurz aufzählen:

1. Bugtraq: @lex Guestbook <=(ModeliXe.php) Remote File Inclusion Exploit
   Hier werden (etwas verwirrend) zwei verschiedene Skripts als verwundbar bezeichnet. Das eine ist eine Konfigurationsdatei, die nur aus define()-Anweisungen besteht und keine include()-Anweisungen o.Ä. enthält. Das andere verhindert durch
   

      
      if (!defined('AGUEST'))
      die("Safety error.");
      

   seinen direkten Aufruf. Da kann noch so viel an den Parametern manipuliert werden – weiter als bis zur die()-Anweisung kommt das Skript nicht. defined() ist nur bei definierten Konstanten true, es hilft also auch nichts, eine gleichnamige Variable zu setzen.
2. Bugtraq: news7 (news.php) Remote File Inclusion Exploit
   Die angebliche Schwachstelle soll
   

      
      require($news7["functions"]);
      

   in news.php sein.
   Genau darüber wird $news7["functions"] jedoch initialisiert:
   

      
      $news7["functions"] = "news7/include/functions.php";
      

   Eine evtl. Manipulation wird also sofort überschrieben.
3. Bugtraq: PHP Cards <= 1.3 Remote File Inclue Vulnerability [sic]
   Die Schwachstelle soll
   

      
      include "$CardPath"
      

   im Skript phpCards.header.php sein.
   Die einzigen Codezeilen, die $CardPath enthalten:
   

      
      $CardPath = "/usr/home/snipe.net/html/phpCards1.3/";
      include "$CardPath"."phpCards.Config.php";
      include "$CardPath"."lang/"."$CardLanguageFile";
      

   Zum einen kommt die angebliche Schwachstelle in der Form gar nicht im Code vor, zum anderen wird die Variable vor der ersten Verwendung initialisiert.
   $CardPath ist einer der Werte, der bei der Installation angepasst werden muss.
4. Bugtraq: RamaCMS (adodb.inc.php) Remote File Inclue Vulnerability [sic]
   Hier befindet sich die angebliche Schwachstelle in einer Funktion, die innerhalb des Skripts gar nicht aufgerufen wird. Abgesehen davon, dass die Variable kurz vor ihrer Verwendung initialisiert wird.

Mal sehen, was es da in Zukunft noch alles an falschen Schwachstellen gibt. Der Ansatz ist ja eigentlich gar nicht schlecht – nur die Durchführung lässt teilweise noch sehr zu wünschen übrig.

Carsten Eilers