News Sofort updaten!: Patches schließen hoch­ris­kante Sicherheitslücken in PHP

Habe mich ehrlich gesagt darüber gewundert, dass ihr als IT-Fachmagazin erst so spät darüber berichtet habt.
 
  • Gefällt mir
Reaktionen: LuxSkywalker, CoMo, 1776 und eine weitere Person
Naja php als Sprache ist nicht das Problem.

Das Problem ist eher das der Interpreter usw in c geschrieben sind.

Vielleicht macht es Sinn mit Claude alles zu rust zu übersetzen ähnlich wie es bei bun js mit zig gemacht wurde.
 
JustAnotherTux schrieb:
Naja php als Sprache ist nicht das Problem.

Das Problem ist eher das der Interpreter usw in c geschrieben sind.

Vielleicht macht es Sinn mit Claude alles zu rust zu übersetzen ähnlich wie es bei bun js mit zig gemacht wurde.
Ich hoffe das die JS rust engine mehr Verbreitung findet und bun oder deno dann darauf setzten das wäre mal eine gute Sache IMO. (komplette runtime und js engine in rust)
 
  • Gefällt mir
Reaktionen: Sherman123 und JustAnotherTux
Der Traum alles paranoiden IT‘ler ist (endlich) wahr geworden, jetzt haben sie endlich mal recht und wir werden nun alle sterben, oder eben auch nicht, vielleicht.
 
  • Gefällt mir
Reaktionen: TheGreatMM
Bin gespannt, wann das überall sauber durch ist. Auch wenn bei mir beispielsweise IONOS die aktuellen PHP Versionen schon eingespielt hat, ist da wohl noch mehr zu tun, im CC kann ich seit gestern Nachmittag fast nichts mehr machen, bekomme nur Fehlermeldungen.

Hat sicher alles auch was mit KI zu tun, ich denke so etwas wird sich häufen. Passiert ja bei so gut wie jeder Software im Moment und hat nichts speziell mit PHP zu tun…
 
Zuletzt bearbeitet:
So einfach scheint das ausnutzen der Lücke dann doch nicht zu sein:
https://markdown.page/AzvY2d69

Und der öffentlich gemachte php2shell exploit soll angeblich nicht wirklich funktionieren oder nur unter sehr spezifischen Voraussetzungen.
Aber ja, Updaten sollte man so oder so.
 
samuelclemens schrieb:
In der regel muss man hier aber jedes mal erst einen Zugang schaffen!?
Genau, bei meinen OpenWRT und OPNsense Routern habe ich z.b. den Zugriff auf ein Management Interface beschränkt, in Erwartung genau solcher Lücken. Wenn man dem verwundbaren Service nicht ansprechen kann, kann man ihn auch nicht Angreifen.

Aber je länger man sich das Drama anschaut je mehr wünscht man der LionsOS Firewall Erfolg.
 
  • Gefällt mir
Reaktionen: samuelclemens
All-inkl war offline. Heute wieder erreichbar. Meine Seiten waren stets erreichbar. Mein Provider bestätigt, dass mein PHP8.5 gepatcht ist.
 
rhapke schrieb:
Meine Seiten waren stets erreichbar
Ob die Seiten auf All-inkl in der Zeit bis zum Patchen der neuesten Version auch wirklich geschützt waren, weiß keiner. All-inkl hat mir darauf keine Antwort mehr gegeben, wobei es bei denen sowieso keine Kommunikation gab, außer einem billigen Instagram-Post (!). (Wobei ich meine Seiten eh sofort per FTP offline genommen hatte.)
 
konean schrieb:
Hm... Bei mir noch nicht. Ich bin etwas enttäuscht von All-inkl, so wie sie das bis jetzt handhaben. Keine Infos, kein Zugang für mehrere Stunden...
Bin auch Großkunde bei denen. Würde ich nicht so sagen. Viele haben ja erstmal abgeschaltet und die Lage sondiert.
 
Ein echtes Problem sind die meisten Billig-Hoster, wo kleinere Seiten für Kleinstbeträge gehostet werden. Bis hin zu V-Servern hat man ja keinen Einfluss und ist dann dem Anbieter hoffnungslos ausgeliefert. Auch Hetzner hat gestern bis kurz vor 17.00 Uhr gebraucht.

Brrr schrieb:
So einfach scheint das ausnutzen der Lücke dann doch nicht zu sein:

Hier muss man trennen, ich beschäftige mich auch seit zwei Tagen intensiver damit. Eine ungepatchte Seite lahmzulegen ist nämlich leider wirklich leicht, also für praktisch jeden machbar:

Worker zum Absturz bringen (DoS) ist easy. Ein einziger präparierter Upload-Request reicht schon, um bei Standardeinstellungen den Speicher eines PHP-Workers zu erschöpfen. Das geht ohne Login, ohne bestimmtes Plugin und bevor WordPress überhaupt läuft. Wiederholt man das, sind die Worker ständig belegt oder stürzen ab. Man kann auch den Speicher ausspähen, denn laut den Analysen ist das teilweise möglich. Darin können dann Teile anderer Requests stecken, im ungünstigen Fall auch Zugangsdaten. Und Bingo!

Die ganze Seite wirklich zu übernehmen ist schwer, aber nachweislich machbar und die Hürde sinkt gerade schnell.

Um fremden Code ausführen muss ein Angreifer mehrere Requests genau auf denselben Worker abstimmen und den Speicher gezielt vorbereiten. Das ist Arbeit für erfahrene Exploit-Entwickler und hängt von PHP-Version, Erweiterungen und Serveraufbau ab. Aber es sollte für Profis keine Hürde sein.

PHP-Projekt hat es ja selbst über HTTP gegen Apache mod_php mit Standardeinstellungen demonstriert und es ging. Bei PHP-FPM ist es aufwendiger; der Session-Weg dorthin ist aber laut Advisory ebenfalls bestätigt.

Die Zeitspanne, in der nur Profis das können, ist erfahrungsgemäß kurz.
 
  • Gefällt mir
Reaktionen: dev/random, Rickmer, LTCMike und 3 andere
ascer schrieb:
PHP ist ja schon ziemlich altbacken und eher 2000er Technologie - oder allenfalls noch 2010er
Weil neue Frameworks kein Selbstzweck sind.

Auch wenn so mancher ITler sich damit gerne Geld verschafft.
 
ascer schrieb:
PHP ist ja schon ziemlich altbacken und eher 2000er Technologie - oder allenfalls noch 2010er.
PHP ist wie Java. Jedes Jahr wir gesagt Java stirbt aus... ähm ja.
Vielleicht macht es Sinn jede Mensch-Computer-Mensch Sprache abzuschaffen und die KI soll einfach eine selbst erfinden.
 
User38 schrieb:
PHP ist wie Java. Jedes Jahr wir gesagt Java stirbt aus...
Abgesehen davon dass es eher Offtopic ist, aber wüsste nicht wieso man PHP und Java gleichsetzen sollte? PHP wird von einer kleinen Gruppe finanziert durch eine Foundation entwickelt. An der Entwicklung von JVM basierten Sprachen und dessen Ökosystems arbeiten Firmen wie Oracle, Jetbrains, Google, Red Had, Netflix, Amazon, Microsoft, IBM, SAP...
Alle Umfragen und Daten aus dem Enterprise Bereich zeigen, dass die Java Verbreitung ziemlich konstant ist und auch viele neue Projekte darauf setzen. Besonders im Backend Bereich und im Bereich Apps für das verbreitetste Betriebssystem (Android).

PHP kommt halt vor allem in CMS Systemen historisch bedingt viel zum Einsatz und hat einen klaren Fokus auf Web Dienste. Dort sinkt auch tatsächlich die Verbreitung in den letzten Jahren.
 
Zuletzt bearbeitet:
Brrr schrieb:
Jein. Es würde etwas bringen wenn das Filesystem oder teile davon nur Read-Only wäre, aber das ginge auch ohne Container. [...]
Ein Container schützt höchstens davor, dass das Host-System nicht übernommen werden kann. Das sollte mit diesem Hack aber auch nicht möglich sein, ausser man nutzt noch eine Lücke im Host-System oder PHP läuft mit root.[...]
fdsonne schrieb:
Du landest über die PHP Lücke bestenfalls im Container des WebServer Prozesses. Dort als unprivilegierter User. Sagen wir www-data, uid 33.
Von hier aus bräuchte es jetzt eine Eskalation über eine aktuell nicht bekannte Lücker aus dem Container. Docker, Podman, k8s, etc.
[...]
Persistieren und Rechteausweitung schön und gut, in dem Moment wo die Shell zur Verfügung steht können Angreifer beliebig Code ausführen. Bis zum nächsten Neustart hat man auf jeden Fall einen Knoten fürs eigene Botnetz. Wobei viele Container für Webanwendungen oftmals irgendwie schreiben können müssen um Aktualisierungen des Inhalts entgegenzunehmen.

fdsonne schrieb:
Viel wichtiger ist die Hausaufgaben VOR Inbetriebnahme irgendwelcher Dienste am Netz zu machen. Wie gesagt, in einer gehärteten Umgebung ist derzeit keine derartige Angriffsstrategie möglich da keine bekannten Lücken mehr existieren. Ein Admin mit Sachverstand weis was er tun muss, damit der Kram safe ist.

Ich zweifle am Sachverstand von Admins, wenn sie ihre Maßnahmen als derart sicher beschreiben.

Brrr schrieb:
Edit: Zeitstempfel steht 13.45 Uhr auf archive.ubuntu.com aber ich weiss nicht, was das für eine Zeitzone ist.
HTTP Response sagt der Server läuft auf GMT/UTC, Es wäre ungewöhnlich wenn in der *nix-Welt was Anderes genutzt wird für Zeitstempel.
 
  • Gefällt mir
Reaktionen: Brrr
Wie prüfe ich anhand der Requests, ob ein Angriff stattfand bzw. ein Exploit genutzt bzw. infiltriert wurde?
 
Zurück
Oben