Tag Archives: Patch

PHP Apocalypse abgewendet

Posted on by

So Freund, wir  sind wieder online. Wieso wieder Online fragt Ihr, na wegen PHP2SHELL !

PHP Apocalypse abgewendet

PHP hat zwar früher als erwartet das Embargo für die PHP Patche freigegeben, aber dank eines Geniestreichs, waren unsere Server schneller wieder am Netz als andere, denn die Mirrors der Updatepakete waren nicht aktuell. Hätte man auf die gewartet, hätte es Stunden dauern können.

Was ist überhaupt passiert:

Security advisory: Critical remote code execution vulnerabilities, update now

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

The vulnerabilities:

  • RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
  • RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.

How to update:

  • Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source downloads are on our downloads page. Windows source and binaries are on the same page.
  • Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.
  • PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.
  • If you rely on the volunteer-maintained rpms.remirepo.net, we urge you to switch to distribution packages or build from source, so you can immediately apply updates. The repo will not have updates today.
  • Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.

If you cannot update immediately: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.

RCE via OOM corruption (CVE-2026-109618):

  • Set memory_limit=-1, preferably in a way applications can’t override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
  • Set a low post_max_size. For applications that don’t require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
  • Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

RCE via stale global state (CVE-2026-109619):

  • Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
  • On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
  • Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.
  • Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.

The advisories linked above have the full technical details.

Quelle: php.net

Da 24h Zeit waren wurden heute Mittag im Geheimen bereits das Update für Fedora kompiliert. Daher konnte man die Pakete bereits früher haben als die Mirrors. Letztendlich wurden die dann über unsere Updateserver verteilt, so daß alle unsere Server das für ein normales Update wie jedes andere behandelt haben.

Follow-Up: Pinephone Gnome Powerbuttonpatch

Posted on by

Moin, Moin,

es tut sich was im Pinephoneland. Meinen Patch habe ich inoffiziell dem Maintainer des entsprechenden Paketes übergeben, nachdem diverse Checks eingebaut wurden, daß das nur passiert, wenn es sich um ein Pinephone oder andere mobile Geräte handelt.

Follow-Up: Pinephone Gnome Powerbuttonpatch

Wer mal sehen möchte:

do_config_power_action (GsdMediaKeysManager *manager,
                        GsdPowerActionType   action_type,
                        gboolean             in_lock_screen)
{

#ifdef __aarch64__
        int status = 0;
#endif
        switch (action_type) {
        case GSD_POWER_ACTION_SUSPEND:
#ifdef __aarch64__
                // only use it on devices that have a mobile-greeter like pinephones
                if( access( "/usr/bin/lightdm-mobile-greeter", F_OK ) == 0 ) {
                        status = system("/usr/bin/dm-tool lock");
                        if ( status == 0 ) {
                               power_action (manager, "Suspend", !in_lock_screen);
                        } else {
                                g_debug ("Execution of LightDM-Lock failed for suspend!");
                          
                                //  TODO: Escalate to OSD, because this is a security problem
                                //        Suspending a device if an intended security feature failes, is out of the question, so we deny it.
                        }
                } else {
                        power_action (manager, "Suspend", !in_lock_screen);
                }
#else 
                power_action (manager, "Suspend", !in_lock_screen);
#endif

Den ganzen Patch gibt es hier, weil Hibernate muß man ja auch abdecken.

https://github.com/Cyborgscode/pinephone/blob/main/gsd-media-keys-manager.c.patch

Jetzt kann nur hoffen, daß der Patch in offizielle Paket kommt. Mein Telefon ist jetzt jedenfalls wieder einen Schritt weiter 🙂

Wer auf seinem Handy Phosh als Desktop nutzt, der hat so einen Patch schon und braucht da nichts machen.

CVE-2019-11500: Heap-Overwrite Lücke in Dovecot

Posted on by

OOB Sicherheitslücke in Dovecot < 2.3.7.2 und < 2.2.36.4 führt schlimmstenfalls zu Remote-Code-Execution. Die Meldung vom Dovecotteam enthält einige Ungereimtheiten, die man mal aussprechen müßte.

UPDATE:  11:56 Uhr : Updates fertig ( Anweisung siehe unten )

Mögliche Remote-Code-Execution in Dovecot

Erstmal schauen wir uns an(siehe Advisory unten), was es für eine Schwachstelle ist: „OOB Write im Pre-AUTH „. Das meint, daß ein Angreifer ohne sich authentifizieren zu müssen, einen „Exploit-String“  an den Service schicken kann, der etwas überschreibt. Genauer betrachtet handelt es sich um einen HEAP Overwrite, d.b. ein Teil des internen Speichers des Prozesses kann durch den Angreifer manipuliert/überschrieben werden.

Das ist insofern kritisch, als daß im HEAP Speicher auch Programmteile und Rücksprungadressen liegen können. Gelingt es dem Angreifer die richtige Speicherstelle mit seinem Code zu überschreiben, führt der Prozess ggf. seinen Code aus, statt dem legitimen Programmcode von Dovecot.

Gelingt dies, hat der Angreifer einen privilegierten Prozess in seiner Gewalt und kann sich von dort weiter nach oben exploiten, weil er einen Fuß in der Tür hat. Da Dovecot in Teilen mit Rootrechten läuft, ist ggf. nicht mehr viel nötig um einen Server zu übernehmen:

root 18590 0.0 0.0 3688 2276 ? Ss 03:06 0:00 /usr/sbin/dovecot
root 18595 0.0 0.0 3640 2196 ? S 03:06 0:00 \_ dovecot/log
root 18617 0.0 0.1 5544 4172 ? S 03:06 0:00 \_ dovecot/config
root 18659 0.0 0.1 16552 8208 ? S 03:06 0:00 \_ dovecot/auth

Gegenmaßnahmen

Es gibt nur die Möglichkeit Dovecot auf die neueste Version zu hieven und da beginnt das Problem für viele Linuxuser, denn z.b. Fedora hat heute erst begonnen neue Versionen zu bauen, obwohl Redhat und das Fedora Team seitdem 14.8. Bescheid wissen.

Wieso das erst heute gemacht wird, liegt in der Einschätzung des Security Teams. Das kam zu der fatalen Fehleinschätzung, daß der OOB auf den Heap ja „extrem schwierig“ wäre, weil der Speicherbereich der überschrieben werden kann, zufällig wäre. Das ein Angreifer dann einfach so lange Exploitversuche wiederholt, bis es zufällig klappt, war dem Security Team offensichtlich nicht ganz klar. In Zeiten von riesigen BOT-Netzen, muß man diese Sicht der Dinge als ziemlich naiv bezeichnen, leider.

Zum Glück gibt es ja findige Blogger, die dem Team klar gemacht haben, wo bei der Einschätzung der Fehler liegt und siehe da …

Package Name dovecot
Version 2.3.7.2
Release 1.fc32
State building
Started Thu, 29 Aug 2019 07:47:34 UTC
Est. Completion Thu, 29 Aug 2019 08:10:40 UTC

Changelog * Thu Aug 29 2019 Michal Hlavinka <mhlavink@redhat.com> – 1:2.3.7.2-1
– dovecot updated to 2.3.7.2, pigeonhole 0.5.7.2
– fixes CVE-2019-11500: IMAP protocol parser does not properly handle NUL byte
when scanning data in quoted strings, leading to out of bounds heap
memory writes

es tut sich was bei Fedora.

Fazit: Manchmal braucht es nur einen, der den Arschtritt vornimmt 😉

Wie gefährlich ist die Lücke wirklich?

Das Problem liegt im Detail. Natürlich gibt es die Speicherverwürfelung von Linux als Schutzmaßnahme, aber das macht es einfach nur schwieriger, nicht unmöglich einen Exploit zu schreiben und auszunutzen. Der Knackpunkt ist genau, daß es nicht unmöglich ist, also muß man es zeitnah beheben. Der Angreifer hat im Worst-Case-Fall unendlich viel Zeit und unbegrenzt Ressourcen zur Verfügung ( eine Beschreibung eines Botnetzes 😉 ) und setz diese auch ein. Er kommt also irgendwann per Zufall durch.

Workround nicht vorhanden

Verschärfend kommt hinzu, daß es keinen Workaround gibt und keine Methode den Angriff verlässlich zu bemerken. Die Logfiles schweigen sich quasi aus:

Aug 29 09:33:26 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured
Aug 29 09:34:16 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured
Aug 29 09:34:17 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured
Aug 29 09:34:18 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured
Aug 29 09:34:19 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured
Aug 29 09:34:19 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured

Was Ihr oben seht, ist mein Versuch mit einem Beispielcode aus dem Advisory eine Logmeldung zu produzieren. Die Meldung kommt aber am Tag auf größeren System so 100-1000 mal vor, weil natürlich andere Angreifer und falsch konfigurierte Mailprogramme unsinnige Verbindungen zum Server aufmachen, ohne sich zu authentifizieren. Nichts, was ein übermäßiges Security Problem darstellt. Dies muß so ein Server einfach aushalten. Von den jetzt anstehenden Versuchen, die verwundbaren Dovecotserver zu exploiten, kann man das bisherige Rauschen aber nicht unterscheiden und das macht einen effektiven Schutz bis zum Update durch Fedora so problematisch.

Ich seh da nur : Port firewallen und per SSH durchtunneln, oder Firwalllücken für Ips aufgrund einer Auth an einem anderen Service, aber macht das mal mit tausenden von Kunden… also eher keine Lösung.

Das Advisory von Dovecot

Kommen wir zu dem Teil, bei dem ich mich fragte, wieso wir überhaupt ein Problem haben. Das Advisory gibt folgende Daten preis:

Date: Wed, 28 Aug 2019 15:06:23 +0300
Open-Xchange Security Advisory 2019-08-14

Vulnerable version: All versions prior to 2.3.7.2 and 2.2.36.4
Vulnerable component: IMAP and ManageSieve protocol parsers (before and
after login)
Solution status: Fixed by Vendor
Fixed version: 2.3.7.2, 2.2.36.4
Vendor notification: 2019-04-13
Solution date: 2019-06-05
Public disclosure: 2019-08-28
CVE reference: CVE-2019-11500

Gefunden wurde das also im April, im Juni behoben und gestern Abend wurde es öffentlich gemacht. Der 14.8. ist der Tag, an dem Redhat/Fedora davon über die distributionsübergreifende Mailingliste erfahren hat. Soweit so gut.

Wenn man sich jetzt aber die „Fixed Version“ und die Buildhistory von Fedora ansieht:

 NVR                   Built by Finished            State
dovecot-2.3.7.2-1.fc32 mhlavink 2019-08-29 08:36:07 complete
dovecot-2.3.7.1-1.fc30 mhlavink 2019-08-19 20:30:43 complete
dovecot-2.3.7.1-1.fc29 mhlavink 2019-08-19 16:12:18 complete
dovecot-2.3.7.1-1.fc32 mhlavink 2019-08-19 13:52:26 complete

Demnach wurde also am 19.8, 4 Tage nach dem internen Advisory, eine verwundbare Version für Fedora gebaut. Da fragt man sich doch „Wieso“, oder nicht?

Was mich jetzt aber wirklich umtreibt ist, daß es ja schon am 5.6. den Fix gab, der vermutlich intern auch schon eingecheckt war in die Sourcecodes und folglich in dem Build 2.3.7.1 hätte vorhanden sein müssen. Laut Github ist die 2.3.7.1. vom 23. Juli, also 1 Monat nach dem Fix:  „ Jul 23, 2019 2.3.7.1 “ .

Ich werde das leider nicht auflösen können, aber falls jemand anderes da mal Licht auf die Commithistorie werfen möchte, fühlt Euch eingeladen. Persönlich kann ich mir gut vorstellen, daß der Fix nicht ganz so foxy war, wie sich der Hersteller das gewünscht hat und er deswegen nicht gleich in den Code kam. Irgendeine andere Begründung, wäre vermutlich nicht so sexy für die Entwickler 😉

Dovecot Advisory in Natura: https://www.openwall.com/lists/oss-security/2019/08/28/3

PS: der FC32 Build ist durch, ich hoffe die anderen kommen auch gleich noch dran.

UPDATE:  11:56 Uhr

Die gefixte Version ist jetzt verfügbar und funktioniert auch ( für x86_64 ) . Ihr könnt direkt als Root Eure Pakete aktualisieren:

Fedora 29:

dnf update https://kojipkgs.fedoraproject.org//packages/dovecot/2.3.7.2/1.fc29/x86_64/dovecot-2.3.7.2-1.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/dovecot/2.3.7.2/1.fc29/x86_64/dovecot-mysql-2.3.7.2-1.fc29.x86_64.rpm

Fedora 30:

dnf update https://kojipkgs.fedoraproject.org//packages/dovecot/2.3.7.2/1.fc30/x86_64/dovecot-2.3.7.2-1.fc30.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/dovecot/2.3.7.2/1.fc30/x86_64/dovecot-mysql-2.3.7.2-1.fc30.x86_64.rpm

Anmerkung: Wer einen anderen Backend als MYSQL benutzt, muß die Anweisung anpassen.