[php] upload-sicherheitsluecke

[Björn Schotte]

* Andre Steffens wrote:
> >Ich warte jetzt mal stündlich darauf das dieses Tool die Runde
> unter den script-kiddies macht und das massen hacking ausbricht.
> Ich weiss nicht was dieses Tool kann aber wenn es kann was ich

Ich sehe es ähnlich wie Sebastian. Es scheint unter bestimmten
Umständen ein ernsthafter Bug zu sein, der in Zusammenhang mit
malloc() steht. Stefan Esser hat mir dazu heute eine E-Mail
geschrieben, die ich hier entgegen der üblichen Konventionen
mal veröffentliche (Stefan ist für zwei Tage nun weg und jetzt
ist die Uhrzeit denkbar schlecht um um Urlaubnis zu fragen):

---------------------------------------------------------------------------
Hallo,

habe eben die Mail gelesen und vom Telefonat gehört.
Also ich bin ab gleich erstmal "out off order" zumindest für die nächsten 2
Tage,
deshalb kurz eine Antwort.

Ich denke mal es gibt keine Postings auf php-dev die viel über die Bugs
sagen,
da eigentlich alles direkt von mir zur PHP Group ging.

Zu den diversen Exploits: Soweit ich es bisher erfahren habe zirkuliert
ein Exploit (welches von XForce analysiert wurde) in Kiddiekreisen.
Dieses Exploit soll laut XForce funktionieren, allerdings nur bedingt
und nur gegen vorkompilierte Versionen, die mit den Distributionen
ausgeliefert werden. Ausserdem soll es sehr unzuverlässig sein.
Anhand der Analyse von XForce, ist es wohl einer der Bugs, die
ich als schwer zu exploiten eingestuft habe.

Das ganze auf einen Punkt gebracht: Im Grunde sind das meiste
defekte Boundarychecks, die es erlauben ein einzelnes Byte ausserhalb
des Buffers auf '\0' zu setzten. Die Bugs unterscheiden sich dabei
in der Art und Weise wie man es triggern kann und wie zuverlässig
bzw. einfach damit ein malloc exploit zu machen ist.
Der PHP3 Bug hingegen ist ein normaler Stringoverflow, der durch
einen logischen Fehler im Code enstanden ist und der merkwürdigerweise
all die Zeit nie entdeckt worden ist.

Die Versionen nach 4.0.7RC2 sind dabei schwer zu exploiten (da
dort die Kontrolle was überschrieben wird nicht so einfach triggerbar ist)
d.h. es ist zwar möglich, aber je nach memory layout (die einzelnen Apache
Childs allokieren und deallokieren ja ständig memory) ist es schwer
oder gar nicht möglich.

Versionen davor sind alle einfacher zu exploiten (da man besser
kontrollieren
kann, was überschrieben wird) und sollten 100% geupdated werden.
Ausserdem scheinen einige das Advisory nicht genau zu verstehen: die
meisten Bugs sind nur auf Linux/Solaris zu exploiten, weil es malloc Bugs
sind.
Der Heap Overflow in PHP3 hingegen ist "dank" emalloc auf vielen Systemen
exploitbar.  (x86 auf jedenfall *BSD, Linux, Windows... andere OS konnte ich
nicht testen)
---------------------------------------------------------------------------

Was man auf jeden Fall darüber hinaus IMHO machen sollte, ist die
Server-Signature "X-Powered-By:" in HTTP Requests abzuschalten[1]. Mit
simplen Tools kann man sicherlich mehrere zehntausend Rechner
pro Stunde nach anfälligen PHP-Installationen mit dieser Signatur
automatisch scannen (bei PHP als Modul-Installation).

Auf http://www.iss.net/ gibt's bei den X-Force Vulnerabilities einen
Artikel zu diesem Thema.

[1]: expose_php = Off in php.ini

-- 
PHP-Support * realitätsnahe Performance-Messungen mit Code-Analyse
    Webapplikationsentwicklung * PHP-Schulungen * Consulting
    
             0700-THINKPHP -*- bjoern_(at)_thinkphp.de