DoS-Angriffe: Hash-Kollisionen können Webserver lahmlegen

28C3

Durch Hash-Kollisionen können Webserver lahmgelegt werden. Betroffen sind fast alle Webserver etwa mit PHP, ASP.Net und Java. Die Kollisionen können durch POST-Abfragen ausgelöst werden.

Artikel veröffentlicht am 28. Dezember 2011, 21:13 Uhr, Jörg Thoma

Julian Wälde und Alexander Klink haben eine Schwachstelle in der Verarbeitung von Hash-Tabellen in Webservern entdeckt. (Bild: CCC)

Die beiden Entwickler Alexander Klink und Julian Wälde haben eine Schwachstelle beschrieben, die in fast allen Webservern ausgenutzt werden kann: Durch das Auslösen von Hash-Kollisionen kann die CPU-Last von Webservern über lange Zeit auf bis zu 99 Prozent erhöht werden. Betroffen sind mehr oder weniger alle modernen Webserver, denn der softwareseitige Fehler ist in den meisten populären Skriptsprachen enthalten, darunter PHP, ASP.Net und Java oder das Javascript-basierte v8 von Google.

Klink und Wälde haben sich inzwischen an die einzelnen Entwickler gewandt. Einige haben bereits Patches für die Schwachstelle bereitgestellt. Angriffe über die Schwachstelle sind noch nicht beobachtet worden. Allerdings kann sie leicht ausgenutzt werden. Durch einen entsprechenden POST-Befehl können Hashtable-Abfragen mit bewusst ausgelösten Kollisionen erfolgen.

CPU auslasten durch Kollisionen

PHP 5 verwendet beispielsweise die Hash-Funktion DJBX33A von Dan Bernstein, um POST-Daten zu verarbeiten. Diese Funktion kann so manipuliert werden, dass sie mehrfache Kollisionen auslöst. Die Abfragegröße über POST ist auf 8 MByte begrenzt und beschäftigt damit eine iCore-7-CPU für etwa vier Stunden. Allerdings ist die Abfrage durch max_input_time begrenzt, unter Ubuntu und BSD Server standardmäßig auf 60 Sekunden. Die 60 Sekunden reichen aus, um etwa 500 KByte an Daten zu übertragen. Die CPU-Last wird ebenfalls mit max_execution_time auf 30 Sekunden begrenzt. Um eine CPU für 30 Sekunden auszulasten, werden 300 KByte an Daten benötigt. Theoretisch benötigt ein Angreifer etwa 70 bis 100 KBit/s für eine komplette Auslastung einer CPU. Mit einer GBit-Verbindung können demnach 10.000 Core-i7-CPUs beschäftigt werden.

ASP.Net nutzt die Hash-Funktion DJBX33X, die ebenfalls von Dan Bernstein stammt. Hier ist die CPU-Zeit normalerweise auf 90 Sekunden begrenzt. Mit einer GBit-Verbindung können hier 30.000 Core-Duo-CPUs beschäftigt werden. Auch verschiedene Java-basierte Webserver sind betroffen, darunter Tomcat, Glassfish oder Jetty, wobei die Größenbegrenzung der POST-Abfrage variiert. Durchschnittlich beträgt sie 2 MByte.

Die Lösung: Hash-Funktion randomisieren

Die beiden Entwickler raten, die Hash-Funktion zu randomisieren. Als Workaround empfehlen sie, die POST-Abfragen zu reduzieren und die CPU-Limits zu senken.

Zahlreiche Hersteller haben bereits reagiert. Für ASP.net bietet Microsoft einen Patch an. Auch die PHP-Entwickler haben den Patch max_input_vars in Version 5.4.0 RC4 eingebaut. Für Tomcat gibt es ebenfalls einen Workaround, für Glassfish steht er noch aus. Für Python wurde ebenfalls noch kein Patch bereitgestellt, was vor allem für den Webserver Plone von Bedeutung ist. Ruby erhielt ebenfalls einen entsprechenden Patch. Perl-Entwickler haben das Problem bereits 2003 erkannt.

Nachtrag vom 29. Dezember 2011, 8:31 Uhr

Microsoft hat einen Patch für ASP.Net zusätzlich zu seinen monatlichen Patchdays angekündigt. Dieser soll im Laufe des 29. Dezember 2011 erscheinen. Nutzer von PHP können ihre Systeme mit Suhosin absichern, das die Einstellung des Parameters suhosin.{post|request}.max_vars enthält.

Ganz allgemein lässt sich das Problem durch Begrenzung der CPU-Zeit reduzieren, was unter PHP mit der Option "max_input_time" und im IIS für ASP.Net über den Parameter "shutdown time limit for processes" möglich ist. Wer nicht drauf angewiesen ist, große Datenmengen hochzuladen, kann zudem die maximale Größe von POST-Request auf wenige KByte beschränken.