Auf einen Blick

Wenn diese vier Wörter sitzen, versteht man den ganzen Bug. Mehr C braucht es nicht.

Lädt ein Browser eine Datei hoch, kommt sie nicht in einem Rutsch an, sondern häppchenweise. Damit eine Seite „47 % geladen“ anzeigen kann, schreibt PHP den Zwischenstand laufend in die Session. Diese Buchführung erledigt die Funktion php_session_rfc1867_progress (benannt nach RFC 1867, dem alten Standard für Datei-Uploads).

Während ein Upload läuft, ruft PHP diese Funktion zu festen Zeitpunkten auf — man kann sie sich als drei Ereignisse vorstellen:

• FILE_START — eine neue Datei beginnt.
• FILE_DATA — ein weiteres Stück dieser Datei ist angekommen (kann sehr oft feuern).
• FILE_END — die Datei ist vollständig.

Bei jedem dieser Ereignisse müssen Zähler hochgesetzt werden: wie viele Bytes insgesamt, und wie viele für die aktuelle Datei. Und genau beim Zugriff auf diese Zähler nimmt PHP eine Abkürzung.

Statt die Zähler jedes Mal neu in der Session nachzuschlagen, merkt sich PHP einmal ihre Speicheradresse. Dafür hält die Struktur php_session_rfc1867_progress (in php_session.h) zwei rohe Zeiger, die mitten in die lebende Session-Datenstruktur hineinzeigen:

So läuft die Buchführung während eines Uploads ab. Wichtig ist, wer die Merkzettel schreibt und wer sie später benutzt:

• FILE_STARTMerkzettel setzen. Beim Start einer Datei notiert PHP die aktuellen Adressen der beiden Zähler (session.c:3091 bzw. 8.4.4:3316 für den Gesamtzähler, session.c:3117 / 8.4.4:3342 für den Datei-Zähler).
• FILE_DATADurch die Merkzettel schreiben. Für jedes angekommene Stück schreibt PHP über die gemerkten Adressen (session.c:3355–3356) — ohne noch einmal nachzuschlagen.
• FILE_ENDNoch einmal schreiben. Am Dateiende wird über den äußeren Zeiger geschrieben (session.c:3375).
• UPDATELesen. Beim Aktualisieren des Fortschritts wird der Zeiger auch gelesen (session.c:3188).

Solange die Session-Datenstruktur unverändert bleibt, ist das harmlos. Das Problem beginnt, wenn PHP diese Struktur zwischendurch wegräumt und neu aufbaut — denn die Merkzettel werden dabei nicht aktualisiert.

Beide Schwachstellen sind derselbe Patzer. Der einzige Unterschied: wie oft der jeweilige Merkzettel überhaupt neu geschrieben wird.

In beiden Fällen entsteht ein Moment, in dem der Merkzettel „Adresse X“ sagt, X aber nicht mehr gültig ist.

Beim zweiten update() — nachdem genug Daten für eine Aktualisierung zusammengekommen sind — liest php_session_initialize() die Session-Datei erneut ein und baut den kompletten Datenbaum neu auf. Dabei passiert dreierlei:

• php_session_track_init() (session.c:244) wirft den vorherigen dekodierten Baum weg.
• zend_hash_update (session.c:3214) ersetzt ihn durch den frisch dekodierten Baum und ruft dabei den Aufräumer der Hash-Tabelle, zval_ptr_dtor, auf.
• zval_ptr_dtor gibt den Speicher des alten Baums an das System zurück. Ab jetzt ist er frei — aber die beiden Merkzettel zeigen noch hinein.

Warum wird der Speicher überhaupt freigegeben, obwohl noch jemand darauf zeigt? Das ist der Referenzzähler-Fehler: add_next_index_zval (zend_hash.c:1192) und add_assoc_zval_ex (zend_API.c) kopieren den Wert per ZVAL_COPY_VALUE — ohne den Referenzzähler zu erhöhen. Dadurch sind die inneren Arrays (current_file[] und files[]) doppelt eingehängt, aber nur mit Zählerstand 1. Wird der alte Baum abgebaut, fällt der Zähler auf null, und die Arrays werden freigegeben — obwohl ein gemerkter Zeiger noch darauf zielt.

Ein abgestürztes PHP wäre ärgerlich, aber harmlos. Das eigentliche Problem: Freigegebener Speicher bleibt nicht leer — er wird wiederverwendet. Der stale Zeiger wird später noch gelesen (session.c:3188) und beschrieben (FILE_DATA :3355–3356, FILE_END :3375). Gelingt es, die freigegebene Stelle mit anderen Daten zu belegen, dann landen diese Lese- und Schreibzugriffe nicht mehr dort, wo sie sollten.

Die Lektion: Ein use-after-free, bei dem über den baumelnden Zeiger gelesen und geschrieben wird, ist nicht nur ein Absturz-Bug — er reicht aus, um die Kontrolle über den ganzen Prozess zu verlieren. Deshalb werden beide CVEs als kritisch eingestuft.

Ausnutzbar ist das Ganze nur unter zusammentreffenden Bedingungen — aber keine davon ist exotisch:

• Der Upload-Fortschritt ist aktiv (session.upload_progress.enabled — Standard: an).
• Sessions werden benutzt (praktisch jede Anwendung mit Login).
• Ein Angreifer kann ein Upload-Formular ansprechen und den Upload so stückeln, dass der Fortschritt mehrfach aktualisiert wird.

Da die ersten beiden Punkte auf sehr viele Standard-Installationen zutreffen, ist die praktische Angriffsfläche groß. Wer den Patch nicht sofort einspielen kann, kann als Sofortmaßnahme session.upload_progress.enabled in der php.ini auf 0 setzen — das schließt beide Lücken, solange keine Anwendung die Fortschrittsanzeige zwingend braucht.

Ein zwischengespeicherter Zeiger ist ein Versprechen: „das, worauf ich zeige, lebt länger als ich.“ Hier wurde das Versprechen gebrochen. Zwei saubere Wege führen heraus:

• Immer auffrischen, sobald sich die Struktur ändern kann — also bei jedem FILE_START und nach jedem Neuaufbau des Baums, nicht nur beim ersten Mal. Das behebt beide Bugs direkt an ihrer Ursache.
• Gar nicht merken, sondern den Zähler jedes Mal frisch über seinen Schlüssel in der Session nachschlagen. Ein kaum messbarer Geschwindigkeitsverlust gegen einen ganzen Schwachstellen-Typ — ein guter Tausch.

At a glance

Get these four words and you get the whole bug. No more C than this.

When a browser uploads a file, it doesn't arrive all at once but in pieces. So a page can show "47% received", PHP keeps writing the running total into the session. That bookkeeping is done by php_session_rfc1867_progress (named after RFC 1867, the old standard for file uploads).

While an upload runs, PHP calls this function at fixed moments — think of them as three events:

• FILE_START — a new file begins.
• FILE_DATA — another chunk of that file has arrived (can fire very often).
• FILE_END — the file is complete.

At each of these, counters have to be bumped: how many bytes in total, and how many for the current file. And it's exactly when reaching those counters that PHP takes a shortcut.

Instead of looking the counters up in the session every time, PHP records their memory address once. For that, the struct php_session_rfc1867_progress (in php_session.h) holds two raw pointers reaching straight into the live session data structure:

Here is how the bookkeeping runs during an upload. What matters is who writes the notes and who uses them later:

• FILE_STARTWrite the notes. When a file starts, PHP records the current addresses of both counters (session.c:3091 / 8.4.4:3316 for the total, session.c:3117 / 8.4.4:3342 for the per-file counter).
• FILE_DATAWrite through the notes. For each arriving chunk, PHP writes via the recorded addresses (session.c:3355–3356) — without looking up again.
• FILE_ENDWrite once more. At the file's end it writes through the outer pointer (session.c:3375).
• UPDATERead. When refreshing the progress, the pointer is also read (session.c:3188).

As long as the session data structure stays unchanged, this is harmless. The trouble starts when PHP tears that structure down and rebuilds it in between — because the notes are not updated when it does.

Both flaws are the same slip. The only difference: how often each note is rewritten at all.

In both cases there is a moment where the note says "address X" but X is no longer valid.

On the second update() — once enough data has arrived for a refresh — php_session_initialize() re-reads the session file and rebuilds the whole data tree. Three things happen:

• php_session_track_init() (session.c:244) throws away the previous decoded tree.
• zend_hash_update (session.c:3214) replaces it with the freshly decoded tree, calling the hash table's destructor zval_ptr_dtor.
• zval_ptr_dtor hands the old tree's memory back to the system. From now on it is free — but the two notes still point into it.

Why is the memory freed at all while something still points at it? That's the reference-count bug: add_next_index_zval (zend_hash.c:1192) and add_assoc_zval_ex (zend_API.c) copy the value with ZVAL_COPY_VALUE — without bumping the reference count. So the inner arrays (current_file[] and files[]) are double-referenced but only at count 1. When the old tree is torn down the count hits zero and the arrays are freed — even though a recorded pointer still aims at them.

A crashed PHP would be annoying but harmless. The real problem: freed memory doesn't stay empty — it gets reused. The stale pointer is later still read (session.c:3188) and written (FILE_DATA :3355–3356, FILE_END :3375). If the freed spot ends up holding other data, those reads and writes no longer land where they should.

The takeaway: a use-after-free where the dangling pointer is both read and written is not just a crash bug — it's enough to lose control of the entire process. That's why both CVEs are rated critical.

Exploitation needs several conditions to line up — but none of them is exotic:

• Upload progress is on (session.upload_progress.enabled — default: on).
• Sessions are in use (virtually every application with a login).
• An attacker can reach an upload form and split the upload so progress is updated more than once.

Since the first two apply to a great many default installations, the practical attack surface is large. If you can't apply the patch right away, an immediate mitigation is to set session.upload_progress.enabled to 0 in php.ini — that closes both holes, as long as no application strictly needs the progress display.

A cached pointer is a promise: "the thing I point at outlives me." Here the promise was broken. Two clean ways out:

• Always refresh it whenever the structure can change — so at every FILE_START and after every rebuild of the tree, not just the first time. This fixes both bugs right at their root.
• Don't cache at all, and look the counter up fresh by its key in the session every time. A barely measurable speed cost against a whole class of vulnerabilities — a good trade.