Ungepatcher Buffer-Overflow in allen PHP Versionen < 26.3.2022

Ihr nutzt PHP, Eurer Code nutzt die Funktion filter_var() und das Builddate liegt vor dem 26.3.2022(macht lieber 27. draus)? Na dann sind Glückwünsche angebracht: Ihr habt eine 0Day-Lücke in Eurem System!

Ungepatcher Buffer-Overflow in allen PHP Versionen < 26.3.2022

Ganz im stillen haben die Entwickler von PHP eine Sicherheitslücke gefixt, die derzeit noch in jeder PHP Version steckt, die vor dem 26.3.2022 kompiliert wurde. Gemacht haben Sie das nur, weil jemand auf der Mailingliste Full-Disclosure einen Post gebracht hat, in dem er/sie sich über den Mangel an Aufmerksamkeit vom PHP_Security-Team beschwerte. Ich finde die Beschwerde geht ok, weil der Fehler im Code einen Buffer-Overflow ermöglicht.

static int _php_filter_validate_domain(char * domain, int len, zend_long flags) /* {{{ */
+static int _php_filter_validate_domain(char * domain, size_t len, zend_long flags) /* {{{ */

Es handelt sich hier um den Klassiker schlecht hin: Signed Integer <=> unsigned Long . Bei Exim war das letztes Jahr ein großes Ding, weil ein Codeaudit u.a. so einen Fehler im Code entdeckt hatte.

Prikär an der Lage ist, daß der Patch zwar im Github ist, aber keine PHP Updates released wurden, ganz im Gegensatz zur Info, daß da ein Buffer-Overflow im Code ist und wie man den benutzt aka sich einen Exploit baut. Ich habe da mal dem Fedora Maintainer einen Hinweis gemailt, mal gucken ob da was geht.

Wer seine PHP Version auf Commitbasis versioniert, den hier müßte Ihr drin haben, sonst wechselt der Appstatus bei Benutzung von filter_var() +extern eingelieferten Parametern von meine auf owned :

https://github.com/php/php-src/commit/771dbdb319fa7f90584f6b2cc2c54ccff570492d

Aus der POC-Exploit Seite:

// filter bypass
var_dump(filter_var(„5;id;“ . str_repeat(„a“, 4294967286) . „a.com“, FILTER_VALIDATE_DOMAIN, FILTER_FLAG_HOSTNAME));

// DoS/Memory corruption
var_dump(filter_var(str_repeat(„a“, 2294967286), FILTER_VALIDATE_DOMAIN, FILTER_FLAG_HOSTNAME));

Ich wette, da hat schon wer nen Exploit in Umlauf gebracht, wenn da so leicht ist.

An der Stelle möchte ich mich gleich noch mal Rene Collét für seine langjährige, ausdauernde Arbeit in Sachen PHP für Linux bedanken. Dem Mann können die Linux-PHP-Anwender gar nicht genug danken! Ihr macht Euch keine Vorstellung davon was der für alle leistet!

Hinweis: mit „Alle Versionen“ sind hier gemeint: PHP 5 >= 5.2.0, PHP 7, PHP 8, PHP 8.1

UPDATE:

Aus dem Umfeld(Autor bekannt) der PHP Security Liste kam dazu folgende Info:

„Wir haben das nicht als Sicherheitslücke klassifiziert, weil man das mit einem (ungenannten) MemoryLimit blockieren kann.“

Und, „es wurde nur in 8.0+ gefixt, nicht in 7.4“ 🙂  Aber, sagen können die ja viel, ausprobieren hilft:

[Wed Mar 30 22:10:37.167712 2022] [cgid:error] [pid 587854:tid 587945] [client x.x.x.x:41412] AH01215: stderr from /etc/httpd/bin/cgiwrap64: PHP Fatal error: Allowed memory size of 536.870.912 bytes exhausted (tried to allocate 4.294.967.318 bytes) in /home/linux-am-dienstagde/public_html/php7.4.x-exploit.php on line 3

Erklärung: „4G“ will er, „512M“ sind in der Master php.ini als Limit drin und unsere Prozessüberwachung mußten wir auch noch überreden damit, noch mal etwas mehr RAM drauf geworfen werden konnte:

[Wed Mar 30 22:17:20.266256 2022] [cgid:error] [pid 1060712:tid 1060735] [client x.x.x.x:41464] AH01215: stderr from /etc/httpd/bin/cgiwrap64: PHP Fatal error: Allowed memory size of 2.122.317.824 bytes exhausted (tried to allocate 4.294.967.318 bytes) in /home/linux-am-dienstagde/public_html/php7.4.x-exploit.php on line 5

Ist eher unwahrscheinlich, daß man bei einem Hoster über 4 GB allokieren darf, pro Script. Ich halt es aber nicht gänzlich für ausgeschlossen 😉

Die Sicherheitslücke ist dann also eher theoretischer Natur.

Linux am Dienstag – Programm für den 31.8.2021

Sprechen wir doch mal über Sicherheitslücken, davon gibt es ja derzeit einige.

Linux am Dienstag – Programm für den 31.8.2021

Bei Linux am Dienstag am 31.8. 2021 geht es ab 19 Uhr u.a. um folgende Themen:

Linux wird 30!
OpenSSH – VPN mit SSH
OpenSSL – Buffer Overflow im SM2 Modul gefixt.
Security – Was ist eine XSS Schwachstelle?
Security – Was ist eine SQL Injection?

Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .

Kleine Anmerkung: Die bisherigen Vorträge findet man jetzt unter https://linux-am-dienstag.de/archiv/ .

An die IT der Stadt Braunschweig in Sachen MAILSERVER

Im Gegensatz zum letzten Lokalbeitrag über Lebensmittel bei Aldi Nord, kommt heute ein weniger ekliges Thema dran … Woher weiß man, daß man mit dem Mailserver der Stadt Braunschweig spricht?

An die IT der Stadt Braunschweig in Sachen MAILSERVER

Liebe IT-Verantworlichen der Stadt Braunschweig,

wie wir Euch 2018 schon einmal mitgeteilt haben, sind Eure SSL-Zertifikate im Mailserver nichts wert. Glauben Sie nicht? Bitte schön:

$ openssl s_client --connect mailin02.braunschweig.de:25 -starttls smtp -verify_hostname mailin02.braunschweig.de
CONNECTED(00000003)
depth=0 C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
verify return:1
---
Certificate chain
0 s:C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
i:C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = BSSUBCA02
---

Was bedeutet die Ausgabe?

Das jemand ein Zertifikat auf „mailin02.braunschweig.de“ ausgestellt hat und anstatt dies von einer anerkannten Autorität (CA) beglaubigen zu lassen, es mit einem anderen selbst gebauten Zertifikat und dessen Schlüssel unterschrieben hat. Das macht natürlich aus dem ersten Zertifikat mailin02.braunschweig.de auch kein anerkanntes Zertifikat, sondern nur ein weiteres Zert, dem man nicht vertrauen kann.

Das Emails bei der Stadt Braunschweig trotzdem eingehen, liegt einfach daran, daß derartige Fehler sooft vorkommen, daß wer ernsthaft die Autorität eines empfangenden Mailserver prüft, kaum noch Emails rausbekommt. Besser macht die Erkenntnis den Fall natürlich auch nicht, es bleibt ein Setupfehler.

Anders läge der Fall, wenn das Zert mit dem Kürzel BSSUBCA02 selbst von einer bekannten CA verifiziert und beglaubigt wäre. Das kann man aber nicht prüfen, weil das dafür nötige Zert nicht mitgeliefert wird. Pech.

Es bliebt also dabei, diesem Server kann man nicht glauben, daß er wirklich die Stadt Braunschweig repräsentiert.

Weiß hier A nicht, was B tut?

Wer sich mal die Webseite unter Braunschweig.de näher ansieht, findet dort ein Zert für „*.braunschweig.de“, ein sogenanntes Wildcard-Zertifikat. Dies ist für alle beliebigen Domainnamen gültig, auch für „mailin02.braunschweig.de„. Wieso man das dann nicht für den Mailserver nimmt, kann ich nicht beurteilen. Das Wildcard Zert ist nicht eingeschränkt auf das Web ( was gehen würde ), es kann also überall eingesetzt werden.

Basierend auf der Erfahrung mit der Stadt Wolfenbüttel ( gleich hier um die Ecke ), würde ich mich jetzt aus dem Fenster lehnen und behaupten, daß das IT-Managementsystem auf Windowsbasis, daß die Stadt einsetzen wird um deren Firewall und Mailserver zu verwalten, den Admins nur die Innenseite des Netzes anzeigt, aber nicht, was außen wirklich los ist. Ich vermute, intern wird schon seit einiger Zeit ein korrektes Zert angezeigt und das uns gezeigte Mailserverzert ist bloß ein Fragment eines Testsetups von früher.

Das „Root CA 2“ Zert der Stadt Braunschweig, ist scheinbar von 2016 und das „mailin02.braunschweig.de“ von 2017, aber mit einer Gültigkeit von 10 Jahren. Dies ist ein typisches Testsetup, denn normale Zertifikate werden nach 1-2 Jahren getauscht.