PHP - ereg - und dessen Folgen!

[ibor]

Da schau her:

Das verfluchte Nullbyte – Teil 1 | burncycle

ist ebenfalls wichtig zu erwähnen und so kann man alle eregs() umgehen :/

Denn wer will schon, dieses Problem haben? Also es scheint, als hätte sich zum Beispiel "Wordpress" keinerlei Gedanken darüber gemacht

Also -> immer eine Handbreit Puffer unterm Code


Gruß Robert

[ibor]

ich überleg mir auch mal n sec scanner zu schreiben ...
mit allen mir bekannten Schwachstellen

Mal schauen obs was wird

greetz Robert

[mermshaus]

Jetzt finden wir bitte mal das Jahr raus, seit dem die ereg-Funktionen als deprecated markiert sind.

[ibor]

Natürlich ist sie das. Aber denk mal an die 'veraltete' mysql Funktion ohne pdo :/ Wird trotzdem noch verwendet! Und okay es mag sein das ereg noch länger veraltet ist aber es wird immer noch verwendet! Und deswegen sollte man dies wissen. Gerade wenn man es mit einem älteren Script zu tun hat.

Wie gesagt wollte ich nur einen weiteren Grund liefern, warum man niemals auf ereg vertrauen sollte

Gruß Robert

[mermshaus]

Übrigens: Die Issue, die der verlinkte Blogeintrag anspricht, existiert zwar, aber der Code dort zur Demonstration ist ungeeignet.

$var = "stringpasst";
$var2 = "stringpasst\0üch";

$wert = ereg("[a-z]",$var); //ergibt true
echo $wert;
$wert = ereg("[a-z]",$var2); //ergibt auch true
echo $wert; 

Beide ereg-Aufrufe ergeben nicht bool(true), sondern int(1). Das ist auch beim zweiten Aufruf zufällig die korrekte Rückgabe, weil das verwendete Pattern nur sicherstellt, dass ein Zeichen [a-z] irgendwo in der Eingabe auftaucht. Anders gesagt: Das Pattern liefert auch für Eingaben wie "123a456" den Wert int(1).

Hier ist eine geeignetere Demonstration der NUL-Byte-Problematik:

var_dump(
    ereg('^[a-z]+$', "abc\x00123") // ergibt int(1)
); 

"\x00" ist hier das NUL-Byte. Dieser Ausdruck sollte bool(false) liefern, liefert aber int(1), da ereg das NUL-Byte wahrscheinlich für das Eingabeende hält (Stichwort nullterminierte Strings).

Dieses Problem tritt tatsächlich nur beim NUL-Byte auf:

<?php // ereg.php

$pattern = '^[a-z]+$';

for ($i = 0; $i <= 255; $i++) {
    $input = 'a' . chr($i) . '1'; // Number in string. Pattern should never match

    if (false !== ereg($pattern, $input)) {
        printf("False positive for byte chr(%s)\n", $i);
    }
}

echo "Done\n";

Ausgabe:

$ php -f ereg.php 
False positive for byte chr(0)
Done

Es scheint für dieses Problem mit ereg also eine Lösung zu sein, vorher NUL-Bytes aus der Eingabe zu filtern. Nutzen sollte man die ereg*-Funktionen natürlich dennoch nicht, da sie seit Mitte 2009 als deprecated gelten und in PHP 7 laut Doku gar nicht mehr existieren.

Der Vollständigkeit halber ein Test für PCRE/preg*-Funktionen:

<?php // pcre.php

$pattern = '/\A[a-z]+\z/';

for ($i = 0; $i <= 255; $i++) {
    $input = 'a' . chr($i) . '1'; // Number in string. Pattern should never match

    if (0 !== preg_match($pattern, $input)) {
        printf("False positive for byte chr(%s)\n", $i);
    }
}

echo "Done\n";

$ php -f pcre.php 
Done

[ibor]

Bravo

[fireweasel]

eregs()...

Denn wer will schon, dieses Problem haben? Also es scheint, als hätte sich zum Beispiel "Wordpress" keinerlei Gedanken darüber gemacht

Gibts da einen Zusammenhang mit Wordpress? (Ich glaube zwar kaum, dass die da noch ereg_...() verwenden, aber man weiß ja nie ...)

Die PCRE-Erweiterung gibts mindestens seit PHP 5.0.0. Seit dieser Zeit besteht also keine Veranlassung mehr, POSIX-Regex-Funktionen zu nutzen. Sie können nichts, was die PCRE nicht auch könnten. Und wer die POSIX-Syntax liebt, nimmt halt die MultiByte-Version. Die sollte per Definition NUL-Byte-sicher sein.

[ibor]

Habe mir den Quellcode auch von wordpress Plugins angeschaut und habe dann diese Feststellung gemacht!

Ob der Code auf GitHub noch aktuell ist weiss ich nicht aber ich habe was wordpress anbelangt auch was gefunden

EDIT: Sorry habe nicht im repository gesucht :/

Aber die Plugins sind wirklich teilweise betroffen - wenn man das so sagen kann :P

Einfach hier her gehen: https://github.com/search?l=php&q=wo...utf8=%E2%9C%93

Gruß Robert

[mermshaus]

WordPress-Core kann allerdings wenig für irgendwelche Plugins. Die kann ja jeder schreiben. Da die Software schon so lange existiert und so verbreitet ist, wird es eben entsprechend viele Plugins geben und auch etliche, die seit Jahren nicht mehr gepflegt werden, deren Code aber noch irgendwo rumgeistert. Zudem müsste man im Einzelfall schauen, ob die jeweilige Nutzung von ereg*-Funktionen tatsächlich problematisch in Bezug auf die in diesem Thread besprochene Sache ist oder ob es einfach nur alter, aber nicht unsicherer oder fehlerhafter Code ist. Das ist ansonsten auch nur ein einziger Programmierfehler, den man machen kann. Man könnte sich genauso gut zig andere Sachen herausgreifen und auch zig andere Software-Projekte. Ich sehe hier jedenfalls keinen Anlass für besondere WordPress-Kritik.

PS: Immerhin hast du es wenigstens inhaltlich versucht. Was man ansonsten teilweise liest, ist leider… Nun ja. (Edit: Auch wenn es in der Übertreibung natürlich auch als Witz gemeint sein soll.)

[NachoV]

Großartig! Tolle Lösung!