Cookies werden nicht korrekt gesetzt

[ChrisB]

Hi,

Das ist genauso pauschal gesagt wie das obige "böse". Code wird nicht serialisiert und es gibt keinen Weg, dass beim unserialize() neuer Code entsteht.

Es kann aber bestehender Code zur Ausführung gebracht werden - und das ohne direkten Zugriff auf diesen Code.

Es werden lediglich Objekte von vorhandenen Klassen mit den serialisierten Eigenschaften wiederhergestellt. Sollte sich der auszunutzende Code nicht bereits im Script befinden, kommt nichts hinzu.

Richtig.
Aber das „jeder“ von außerhalb von einer beliebigen Klasse in meinem System eine Instanz erstellen kann, muss ich nicht unbedingt wollen.

Würde $page gar nicht als Objekt behandelt, kommen lediglich die magischen Methoden wie __toString() in Frage.

Die reichen doch unter entsprechend günstigen Umständen aber schon.
$page braucht es dazu gar nicht - es reicht, wenn du im Script etwas „unverdächtig“ aussehendes wie
echo unserialize($_COOKIE['foo']);
stehen hast.

Bei entsprechendem Cookie-Inhalt erzeugt unserialize ein Objekt, und dessen __toString-Methode wird aufgerufen, sofern vorhanden - und das würde Ausführung von Code bedeuten, die in obiger unschuldiger Script-Zeile sicher nicht beabsichtigt war.

So pauschal würde ich mich hüten, die Größe der Sicherheitslücke bestimmen zu wollen. Da muss schon einiges zusammenkommen, um ausgenutzt zu werden. Aber ja, Sicherheitslücke bleibt Sicherheitslücke, egal ob sie "groß" oder "klein" ist.

Mehrere kleine Lücken, geschickt vom Angreifer kombiniert, ergeben eine große ...

Ich kann halt jede beliebige andere Klasse, die dem Skript an dieser Stelle zur Verfügung steht, instanziieren lassen. Wenn Autoloading im Spiel ist, wird das richtig spannend.

Das ist eine der Einschränkungen, es muss sich um bereits vorhandene Klassen handeln. Und das Autoloading muss man auch erst einmal beeinflussen können.

Wenn es pauschal genug umgesetzt ist, so wie es bspw. das Primitivbeispiel im Manual „vormacht“,

function __autoload($class_name) {  
    include $class_name . '.php';  
}

lacht sich der Angreifer doch schon ins Fäustchen.

Ja, ich weiß, würdest *du* nicht so umsetzen - machen andere Leute aber vielleicht, und denken sich nicht viel dabei. Und mit dieser „klitzekleinen-was-soll-denn-schon-passieren“-Schwachstelle, und der ebenso unscheinbaren, die das Unserialisieren eines Cookie-Wertes darstellt - haben wir jetzt zwei, die in *Kombination* schon sehr viel mächtiger sein können, als sie einzeln den Anschein haben mögen.

Wenn ich das kann, brauch ich keine Kekse, um ungewollten Code ausführen zu lassen, denn dann kann ich gleich den gewüschten Code unterschieben.

Nein - Zugriff auf dein System o.ä. brauche ich im geschilderten Szenario in keinster Weise.

Aber du zieltest auf __autoload() ab und nicht auf auto_prepend_file. Dann gelten wieder obige Einschränkungen, dass gleichnamige Methoden vorhanden sein müssen.

Nur dann, wenn das durch Unserialize erstellte Objekt „weiterverarbeitet“ werden soll. Eine __wakeup- oder __toString-Methode kann allein durch die Erzeugung bzw. durch Ausgabe in einem String-Kontext aufgerufen werden.

Ein weiteres „ich weiß“ - diese Methoden würden bei *dir* keinerlei Schaden anrichten können, OK.
Aber willst du für alles, was im Umfeld eines Open-Source-Systems wie bspw. Wordpress an Plugins und sonstigem durch die Gegend schwirrt, deine Hand ins Feuer legen ...?

Ein Hobby-Scripter, der in seinem hübschen kleinen Kommentar-Plugin die unserialize-Lücke einbaut, um wie schon in meinem anderen Beitrag als Beispiel erwähnt die Vorbelegung des Namens-Feldes in einem Formular zu realisieren,
plus ein weiterer, der vollkommen unabhängig vom ersten es für eine gute Idee hält, seine Klasse XY mit einer __wakeup-Methode zu versehen, die beim Erwachen des Objektes irgendwelche Daten „aufräumt“ (Dateien/Datensätze löscht)

• macht in der Summe bei einem Open-Source-System, wo ich mit den kompletten Quellcode anschauen und in Ruhe nach solchen „kleinen“ Lücken durchsuchen kann, eine Lücke, wo ich durch einen simplen HTTP-Request von außen Daten im System zerstören kann, ohne dass das jemals von irgend jemandem so beabsichtigt war.

Eine einfache Lösung gegen das Instantiieren ungewollter Klassen mit dieser Unserialize-Lösung wäre, anschließend die Klasse zu prüfen.

Im Falle einer bei der Re-Instantiierung aufgerufenen __wakeup-Methode - too late.

MfG ChrisB