soeben lese ich, daß es zwei schwerwiegende Sicherheitslücken in PHP gibt, auf dem viele beliebe Content-Management-Systeme, Blogs, Webshops und Webseiten laufen. Meldungen gibt es beim BSI [1], bei Heise [2] und die CVEs finden sich hier [3] und hier [4].
Die Sache liest sich wirklich übel, anscheinend kann ein Remote-Angreifer beliebigen Code auf dem Webserver im Kontext des PHP-Prozesses ausführen. Außerdem sind anscheinend viele PHP-Versionen ab Version 5 betroffen.
Die Empfehlung ist, die Systeme so schnell wie möglich offline zu nehmen, bis die Patches eingespielt sind.
Hallo,
soeben lese ich, daß es zwei schwerwiegende Sicherheitslücken in PHP
gibt, auf dem viele beliebe Content-Management-Systeme, Blogs, Webshops
und Webseiten laufen. Meldungen gibt es beim BSI [1], bei Heise [2] und
die CVEs finden sich hier [3] und hier [4].
ÖR und Privat-TV haben die Warnung auch schon verbreitet, es scheint also wirklich wichtig zu sein.
ÖR und Privat-TV haben die Warnung auch schon verbreitet, es scheint
also wirklich wichtig zu sein.
Satire?
Im allgemeinen verbreiten sich IT-Sicherheitswarnungen über diese Nachrichtenportale nicht so adhoc, wie ein Stolpern eines US-Präsidenten oder ein Papsthüsteln.
Im allgemeinen verbreiten sich IT-Sicherheitswarnungen über diese
Nachrichtenportale nicht so adhoc, wie ein Stolpern eines US-Präsidenten
oder ein Papsthüsteln.
"Chregu" wollte uns nur mal wieder mitteilen, dass er ein Schwurbler ist und den "Mainstream-Medien" misstraut. Stattdessen vertraut er lieber den Telegram-Kanälen von St. Petersburger "Influencern".
Hallo,
soeben lese ich, daß es zwei schwerwiegende Sicherheitslücken in PHP
gibt, auf dem viele beliebe Content-Management-Systeme, Blogs, Webshops
und Webseiten laufen. Meldungen gibt es beim BSI [1], bei Heise [2] und
die CVEs finden sich hier [3] und hier [4].
ÖR und Privat-TV haben die Warnung auch schon verbreitet, es scheint
also wirklich wichtig zu sein.
Wer mich häufiger liest, dürfte wissen, daß ich solche Threads nicht für Pipifax starte.
Im allgemeinen verbreiten sich IT-Sicherheitswarnungen über diese
Nachrichtenportale nicht so adhoc, wie ein Stolpern eines US-Präsidenten
oder ein Papsthüsteln.
"Chregu" wollte uns nur mal wieder mitteilen, dass er ein Schwurbler ist
und den "Mainstream-Medien" misstraut. Stattdessen vertraut er lieber
den Telegram-Kanälen von St. Petersburger "Influencern".
Ach, der "Chregu". Niemand schafft es so oft, keine Erwartungen zu unterbieten.
Wer mich häufiger liest, dürfte wissen, daß ich solche Threads nicht für
Pipifax starte.
Du bist allerdings mit der Meldung viele Stunden zu spät dran…
Für dieses Forum? Kann sein, kann auch nicht sein. Aber in diesem Fall ist es vermutlich besser, die Meldung mehrmals zu sehen, als sie einmal zu verpassen.
Heute Morgen kam die Meldung, heute um 16:00 wurde die entscheidenden Details der Lücke veröffentlicht. Bis dahin hatte man Zeit, seine Server upzudaten oder vom Netz zu nehmen (was sehr viele getan haben). Wers um 18:12 noch nicht gewusst hat, hat’s verpennt.
Heute Morgen kam die Meldung, heute um 16:00 wurde die entscheidenden
Details der Lücke veröffentlicht. Bis dahin hatte man Zeit, seine Server
upzudaten oder vom Netz zu nehmen (was sehr viele getan haben).
Nein, um 16:00 (bzw. ein paar Minuten vorher) wurde das Update veröffentlicht.
Heute Morgen kam die Meldung, heute um 16:00 wurde die entscheidenden
Details der Lücke veröffentlicht. Bis dahin hatte man Zeit, seine Server
upzudaten oder vom Netz zu nehmen (was sehr viele getan haben).
Auch die gepatchten Versionen wurden erst gegen 16:00 Uhr veröffentlicht. Du hättest was schreiben können, als es bei Dir angekommen ist. Hast Du aber nicht. Oh.
Was willst Du eigentlich von mir? Wenn Du jemanden suchst, dem Du ans Bein pinkeln kannst, bist Du bei mir an der flashcen Adresse: Segler sind wasserdicht.
Kann man sowas nicht gleich von Anfang an wasserdicht
programmieren?
Du hast da also null Ahnung.
Keine Ahnung, wo man da anfangen sollte, Dir etwas zu erklären.
Hast Du in Deinem Leben schon einmal wahrgenommen, dass Dir ein Fehler unterlaufen ist?
Gestolpert, etwas runtergefallen, ein Wort falsch geschrieben oder Zeichen falsch gesetzt/unterlassen?
Kann man sowas nicht gleich von Anfang an wasserdicht
programmieren?
Du hast da also null Ahnung.
Keine Ahnung, wo man da anfangen sollte, Dir etwas zu erklären.
Hast Du in Deinem Leben schon einmal wahrgenommen, dass Dir ein Fehler
unterlaufen ist?
Gestolpert, etwas runtergefallen, ein Wort falsch geschrieben oder
Zeichen falsch gesetzt/unterlassen?
Es wurden doch im Lauf der Jahre sicherlich schon Erkenntnisse gesammelt,
wie solche Angriffe erfolgen.
Wird die Software vorher nicht getestet?
Kann man sowas nicht gleich von Anfang an wasserdicht programmieren?
Schwierig bis unmöglich. Je nach Komplexität.
Allerdings muss man konstatieren, das PatchHackPatch die wohl mit großem Abstand schlimmst mögliche Sicherheitskatastrophe ist. Was aber nicht bedeutet, dass man sie nicht in einem oder zwei Jahrhunderten in etwas zumindest halbwegs Akzeptables verwandeln könnte. Na ja zugestanden, das sind Träumereien. Passiert jedem mal.
nodejs hat übrigens zeitgleich auch eine üble remote code exec Lücke, plus noch weiterer Lücken, plus dem Zertifikate-Krampf mit eMudhra der auch gleich gefixed wird.
Patchen ist nicht alles. Ein funktionierendes, frisches Backup mehr im Schrank zu haben könnte später auch hilfreich sein. Jedenfalls sollte man sich dieses Datum 21.10.2026 gut merken, damit man später keine faulen Backups einspielt.
Jedenfalls sollte man sich dieses Datum 21.10.2026 gut merken, damit man
später keine faulen Backups einspielt.
Wer erstellt heute noch ein Backup vom System? Die Daten sind wichtig, die Systeme werden in der Regel vollautomatisch scriptgesteuert aufgesetzt und konfiguriert.
Es gibt noch einen auch ziemlich kritische Lücke mit korrumpierten
Zertifikaten.
Denn diese Lücke betrifft jeden Internet-Nutzer, im Gegensatz dazu der
PHP issue nur Server.
Sehr richtig, aber in diesem Thread leider deplatziert.
Andererseits zeigt der Vorfall mit den kompromittierten Zertifikaten nur einmal mehr, warum man sein System und seinen Browser stets aktuell halten muß.
Quark, du kennst vermutlich keinen Stack-Overflow oder andere C-Probleme. Du kennst nur die persönliche Ebene, und die persönliche Ignoranz spielt hier mit rein. Also praktisch genau das, was bei dir auch im Alltag mitläuft. Spiel mal lieber mit Python weiter und beleidige Leute, die dich kritisieren.
Quark, du kennst vermutlich keinen Stack-Overflow oder andere
C-Probleme.
Du hast mitbekommen, dass es hier eine von außen ausnutzbare Lücke in einer Software ist, die auf wirklich vielen Webservern läuft? Wieviele Stack-Overflows (also Anfängerfehler) und sonstige C-Probleme mit dieser Tragweite kannst du für die letzten zwanzig Jahre so aufzählen, wenn du Typs „Die Sache liest sich wirklich übel“ als Quark bezeichnest?
Die Sache ist übel. So übel, dass der Beitrag oben halt für jemandem, der da reagieren müsste, viel zu spät kam. Für jemanden, der eh nix mit Servern zu tun hat, ist eh egal.
Ein komplett KI-generiertes Slop-Repo ist jetzt aber auch irgendwie
keine brauchbare Primärquelle...
Doch, natürlich, denn in diesem Repo ist alles vorhanden -- und noch viel mehr: technische Analyse, Exploits, Testskripte, die Laborumgebung für eigene Versuche und sogar Regelwerke für Web Application Firewalls und Intrusion Detection. So ausführliche Informationen würde ich mir öfter wünschen, das ist informativ, sinn- und wertvoll.
Das nur deswegen abzulehnen, weil eine KI daran beteiligt war, wäre mindestens naiv -- um die mildeste Vokabel zu benutzen, die mir dazu einfällt.
Interessant ist dass die PHP-Jockel schon zwei Jahre an der einen Lücke arbeiten, da sie sich nicht vernünftig schliessen lässt ohne massive Kompatibilitätsprobleme. Die wurde damals bekannt als sie einen Audit machten. Jetzt wurde diese und eine andere Lücke eben auch von anderen (KI-Bedienern) entdeckt und die Kacke ist am dampfen.
Erfahrungsgemäss ist das Ganze noch nicht vorbei, da werden in Kürze weitere Löcher in den gefixten Versionen gefunden werden, das ist amtlich.
Es geht um die Tragweite. Ob du PHP magst oder nicht, ist dabei völlig unerheblich – mit einiger Wahrscheinlichkeit nutzt du es mehrere hundert Mal am Tag, und mit ebensolcher Wahrscheinlichkeit hast du schützenswerte Daten auf Maschinen, die PHP verwenden – sei’s dein Webmailanbieter, sei’s deine Bank oder irgendwas Anderes.
Jedenfalls sollte man sich dieses Datum 21.10.2026 gut merken, damit man
später keine faulen Backups einspielt.
Wer erstellt heute noch ein Backup vom System? Die Daten sind wichtig,
die Systeme werden in der Regel vollautomatisch scriptgesteuert
aufgesetzt und konfiguriert.
Das sehe ich selbst zwar grundsätzlich ganz genau so wie Du, aber ich kenne auch die Praxis mancher Serverbetreiber. Besonders im PHP-Umfeld hat Software oft eine starke Abhängigkeit von der verwendeten PHP-Version. Beides wird dann einmal installiert und danach kaum mehr gepflegt, und mit zunehmender Zeit wird es immer schwieriger, die alte Software auf Versionen zu aktualisieren, die mit aktuellen PHP-Versionen funktionieren.
Dabei habe ich selbst schon erlebt, daß manche PHP-Software sogar auf eine Minor-Version von PHP festgezurrt war. Etwa bei meiner Containerisierung des Typo3-basierten NEOS-CMS vor etwa drei Jahren wollte die Software weder mit PHP 8.2 arbeiten, noch mit dem damals aktuellen 8.4, sondern sie bestand auf PHP 8.3. Höchstwahrscheinlich heißt das, daß PHP sich schon zwischen zwei Minor-Versionen unter Umständen so deutlich verändert, daß die Entwickler mancher Software sich nicht auf die Kompatibilität zu den benachbarten Minor-Versionen verlassen wollen (oder können). Wenn die Annahme zutrifft, wären das schlechte Neuigkeiten für Betreiber mit begrenzten Ressourcen oder Fähigkeiten. :-(
Dies ganz unabhängig davon, daß im PHP-Umfeld häufig eine fragwürdige Sicherheitskultur gelebt zu werden scheint. Das PHP-CMS Joomla zum Beispiel benötigt nicht nur für seinen webbasierten Installer, sondern auch im laufenden Betrieb Schreibrechte auf Verzeichnisse, in denen sich Konfigurationsdateien und Code befinden. Nur um das ganz klar zu sage: dort geht es um Software, die in einem nicht vertrauenswürdigen Netz betrieben werden und die nicht vertrauenswürdige Daten verarbeiten soll, die dabei gleichzeitig dauerhaft auf ihre eigenen Konfigurationsdateien und ihren eigenen Code schreiben kann. Daß sich mir bei so etwas geradezu die Fußnägel aufrollen, scheint aber allein mein Problem zu sein.
Quark, du kennst vermutlich keinen Stack-Overflow oder andere
C-Probleme. Du kennst nur die persönliche Ebene,
... sprach er, um dann sofort persönlich anzugreifen:
und die persönliche
Ignoranz spielt hier mit rein. Also praktisch genau das, was bei dir
auch im Alltag mitläuft. Spiel mal lieber mit Python weiter und
beleidige Leute, die dich kritisieren.
Wow, so einen feinsinnigen Humor hätte ich Ihnen gar nicht zugetraut. :-D
Die Sache ist übel. So übel, dass der Beitrag oben halt für jemandem,
der da reagieren müsste, viel zu spät kam.
Zu spät ist es erst, wenn Server oder Daten kompromittiert wurden. Das Bekanntwerden von Sicherheitslücken bedeutet nämlich gemeinhin nicht, daß alle hiervon betroffenen Systeme
gleichzeitig und sofort kompromittiert worden sind.
Für jemanden, der eh nix mit
Servern zu tun hat, ist eh egal.
Ach, ich weiß nicht. Ich persönlich werde in nächster Zeit jedenfalls keine sensiblen Daten in eine PHP-basierte Software eingeben.
Interessant ist dass die PHP-Jockel schon zwei Jahre an der einen Lücke
arbeiten, da sie sich nicht vernünftig schliessen lässt ohne massive
Kompatibilitätsprobleme. Die wurde damals bekannt als sie einen Audit
machten. Jetzt wurde diese und eine andere Lücke eben auch von anderen
(KI-Bedienern) entdeckt und die Kacke ist am dampfen.
Erfahrungsgemäss ist das Ganze noch nicht vorbei, da werden in Kürze
weitere Löcher in den gefixten Versionen gefunden werden, das ist
amtlich.
Kannst Du bitte seriöse Quellen für Deine Behauptungen angeben? Danke.
Weiß ich selber auch. Du kennst aber wahrscheinlich auch keine Stackprobleme? Hauptsache Zeigefinger hochhalten und Dummheit unterschieben? Das gehört sich hier auch nicht.
Du hast mitbekommen, dass es hier eine von außen ausnutzbare Lücke in
einer Software ist, die auf wirklich vielen Webservern läuft?
Na klar. Ja und? Ich mochte PHP von Anfang an nicht. Und du? Kennst du
keine C-Probleme?
Allgemeine "C-Probleme" sind allerdings nicht Gegenstand dieses Threads. Hier geht es um zwei ebenso aktuelle wie akute Sicherheitslücken in PHP.
Dieser Thread soll PHP-Nutzer warnen und sie idealerweise veranlassen, ihre Installationen schnellstmöglich zu aktualisieren. Es gibt nämlich auch in diesem Forum zahlreiche Nutzer dieser Sprache. Ob die Sprache Ihnen (oder Jack oder mir) gefällt, spielt für diese Nutzer und deren Installationen offensichtlich keine Rolle. Gefährdet sind sie trotzdem, solange sie ihre Installationen noch nicht aktualisiert haben.
Sofern Sie über die genannten Sicherheitslücken in PHP diskutieren möchten und auf Ihre persönlichen Angriffe auf andere Teilnehmer dieses Threads verzichten können, sind Sie hier in diesem Thread natürlich herzlich willkommen.
Wenn Sie über allgemeine oder besondere Probleme im Zusammenhang mit anderen Sprachen als PHP, oder über andere Probleme als die im Ausgangsbeitrag erwähnten PHP-Sicherheitslücken sprechen möchten, dann eröffnen Sie dazu bitte Ihren eigenen Thread. Vielen Dank.
Im Frühjahr/Sommer drückten sich die Linux-Bugs die Klinke in die Hand. Nun machen die KIs eben einen Zielwechsel auf andere Produkte. Hej, wie brauchen dringend neue Datacenter für die Bugsucher und Exploitbauer.
Also entweder wird die real eingesetzte Software dadurch sicherer, oder wir graben über kurz oder lang im Keller nach alten Faxgeräten.
Und welcher Kontext wird da aus Sicherheitsgründen wird emfohlen ?
eigener user für php-Anwendungen/-Interpreter ohne shell und login ?
zu dem php-user passende file permissions ?
In meinen Threads möchten Sie bitte korrekt mit Bezug zum zitierten Beitrag zitieren, so wie die Forensoftware das vorsieht.
Ob der PHP-User eine Shell oder einen Login hat, interessiert im Kontext der hier besprochenen Sicherheitslücken nicht.
Auch mit restriktiven Permissions -- was, wie in meinem Beitrag [1] bereits aufgezeigt, bei PHP-Software bisweilen auch so eine Sache sein kann -- wird ein PHP-Prozess häufig auf sensible Daten zugreifen können, etwa eine Datenbank oder Ähnliches.
Wenn ein Angreifer eine Shell starten kann, kann er womöglich weiteren Schadcode aus dem Internet nachladen und ausführen, zum Beispiel um andere Ziele anzugreifen, Spam zu verteilen, oder seine Privilegien zu erweitern.
Cool, dankeschön. Wenn ich allerdings lese, daß das PHP-Team schon seit zwei Jahren an einer dieser Sicherheitslücken herum gedoktort hat, sie also schon mindestens so lange bekannt war, finde ich das schon echt gruselig.
Dass dort vermutlich noch mehr Fehler schlummern stammt von mir, das ist
allgemeiner Konsens bei solchen Lücken die sich nur schwer ausbügeln
lassen.
Nach allem, was ich bisher darüber gelesen habe, vermute ich das ebenfalls. Zumindest bei einem der Fehler scheint es ja um ein grundsätzliches strukturelles Problem zu gehen. Das ist wohl auch einer der Gründe für die Schwierigkeit, einen Patch zu entwickeln.
Für jemanden, der eh nix mit Servern zu tun hat, ist eh egal.
Diese Einschränkung wird allgemein in Frage gestellt, da wird auch von "web-application" gesprochen und das ist auch "irgendwas, das ein Web-Interface (PHP-basiert) für Einstellungen/Status anbietet", beispielsweise ein NaS oder ein Router.
Die unmodifizierten Fritzen sollen wohl nicht betroffen sein, D-Link, ZyXel, etc. pp. schon eher:
Die unmodifizierten Fritzen sollen wohl nicht betroffen sein, D-Link,
ZyXel, etc. pp. schon eher:
Abgesehen davon, daß man nicht alles, was irgendwer irgendwo irgendwie ins Internet rotzt, glauben sollte, hat kein Router oder NASA ein php-Interface zum Internet, wenn das nicht irgend jemand absichtlich installiert und dazu noch freigeschaltet hat.
Als ich vor vieeelen Jahren mal CGI-Programmierung gemacht habe, hab ich mir auch PHP angeschaut. Das kam mir von Anfang an verquer vor und ich hab es als Internet-BASIC bezeichnet. Alleine schon die Idee, jedesmal bei einem Abruf die Seite neu zu generieren fand ich damals seltsam.
Hab mir dann was in Perl geschrieben, das, wenn die Seite neu generiert werden musste, die Seite einmal generiert und da drauf zugreift.
Später dann hab ich WebObjects verwendet. Das war eine richtig geniale Entwicklungsumgebung ohne Gebastle. WebObjects lebt noch weiter als GNUStep, auch wenn Apple es schon lange eingestellt hat.
Es wäre an der Zeit, selbst ein Tool laufen zu lassen,
wo überall dieser böse Code versteckt ist. Viele Vorschaltseiten könnten schon ein Risiko beinhalten?
Kann man sowas nicht gleich von Anfang an wasserdicht
programmieren?
In begrenztem Umfang kann man zwar Software so schreiben, dass sie die Spezifikationen beweisbar einhält. Abgesehen von exorbitanten Kosten reicht das leider nicht:
Wenn das Problem bereits in der Spezifikation steckt. Annahmen, Denkfehler, etwas übersehen... Oft hakt es schon auf dieser Ebene.
Weil Hardware ihrerseits Macken und Lücken hat. Jede gängige Hardware hat sie. Auch Sidechannel Attacks wie Specte und Meltdown können die schönsten Theorien zur Zuverlässigkeit von Software über den Haufen werfen.
Es wäre an der Zeit, selbst ein Tool laufen zu lassen,
wo überall dieser böse Code versteckt ist. Viele Vorschaltseiten könnten
schon ein Risiko beinhalten?
Es gibt darauf spezialisierte Unternehmen.
Das kann dich vor den Richter bringen, wenn nicht vorher explizit vereinbart.
Abgesehen davon, daß man nicht alles, was irgendwer irgendwo irgendwie
ins Internet rotzt, glauben sollte, hat kein Router oder NASA ein
php-Interface zum Internet, wenn das nicht irgend jemand absichtlich
installiert und dazu noch freigeschaltet hat.
Aber sie sind halt im LAN. Und wenn man „aus Versehen“ in einem LAN oder VPN fremder Leute gelandet ist, ist so’n problemlos aufzumachender Router oder ein anderes Device mit Webinterface auf PHP-Basis schon ziemlich nett. Und dann waren da noch Captive-Portale, wie sie bei vielen WLAN-Angeboten zum Einsatz kommen – ich finde, Bradward hat hier durchaus einen Punkt.
@Jack Ja natürlich. Man fängt an der Peripherie an, da ist es brandeilig, und hangelt sich dann nach innen, über interne weit zugängliche Systeme bis zu abgesicherten Systemen. Da sind nicht nur ohnehin berüchtigte Homerouter mit von der Partie, auch schweineteure Enterprise-Speichersysteme. Das zieht sich hin.
b) ein recht altes Problem aktuell mit hypest, also auch kein
Low_Level-KnoHow
hast.
Ich glaube fast, du hast da tatsächlich das aktuelle Ereignis mit irgendwas Anderem verwechselt. Das würde auch deine wirren Beiträge erklären, die so gar nicht zu dem Thema hier passen wollen.
Man muss schon 30 Jahre geschlafen haben, wenn man jetzt erst von PHP als Sicherheitsrisiko überrascht wird.
Sicheheit war bei der PHP Sprache, dem PHP Interpreter und noch mehr bei den Anwendungen schon immer problematisch. Wenn man sich die Entstehungsgeschichte von PHP anschaut (oder wie ich mit erlebt hat), dann erstaunt das kein bisschen. Es war von Anfang an ein Baukasten für Q&D Lösungen, wo Sicherheit noch kein Thema war. Sicherheit wurde wie bei Windows erst nach und nach ergänzt - mit ebenso mäßigem Erfolg.
Wenn ich allerdings lese, daß das PHP-Team schon seit zwei Jahren an
einer dieser Sicherheitslücken herum gedoktort hat, sie also schon
mindestens so lange bekannt war, finde ich das schon echt gruselig.
Ich glaube, gruselig ist die Situation eher, weil so viele scheinbar professionelle Anwendungen auf Hobbyprojekten von Leuten basieren, die das ganze völlig unprofessionell machen. Damit will ich nicht die Autoren herabwürdigen. Es ist toll, dass sie ihr Werk kostenlos zur Verfügung stellen. Falsch ist nur, wie das dann benutzt wird. Für ernsthaft wichtige Dinge war PHP nie gedacht, und deren Autoren können, wollen und sollen das meiner Meinung nach auch nicht leisten.
Das ist das übliche SW-Problem, wenn eine kleine, funktionierende Lösung plötzlich aufgeblasen wird, weil es "so schön" geht. War bei Excel für 2 Leute auch schon so, nur jetzt etwas komplexer mit allen Folgen.
Wenn ich ein Chef eines Secret Service wäre und das meine Backdoor wäre, dann würde es reichen 007 loszuschicken um die Lücke wieder zu schließen. Aber wenn es die KI war, schwierig, sehr schwierig, das überfordert dann sogar 007.
Früher war das auch so, dass einige Leute Werbung dafür gemacht hatten, Webseiten mit Haskell zu erstellen. Und wie lief das damals ab? Auf die wurde auch herumgehackt. So also schau noch mal nach ganz oben was ich da geschrieben hatte. Das ist nicht nur ein technisches Problem.
Jaja, immer auf mir herumhacken. Kennst du das hier?
Kenne ich. Was möchtest du damit sagen? Ich hacke auch nicht auf dir rum, ich versuche lediglich, dich mit zunehmender Deutlichkeit darauf hinzuweisen, dass deine die anderen User abwertenden Beiträge so gar nicht zum Thema des Threads passen.
Ich schreibe meine Webseiten übrigens in HTML, CSS und JS – ein Browser, der Haskell interpretiert, ist mir nicht bekannt. Im Backend kann man eh machen, was man will – beispielsweise ist die Sprache meiner Wahl hier Python.
Der Thread handelt aber nun einmal von einem Problem mit PHP – was du da mit deinem C-Gefasel möchtest, bleibt unklar. Ich schrieb ja oben schon, dass es letztlich ein Fehler in C war, denn PHP wurde zum großen Teil in C geschrieben, aber das scheinst du ja nicht zu meinen?
Als ich vor vieeelen Jahren mal CGI-Programmierung gemacht habe, hab ich
mir auch PHP angeschaut. Das kam mir von Anfang an verquer vor und ich
hab es als Internet-BASIC bezeichnet. Alleine schon die Idee, jedesmal
bei einem Abruf die Seite neu zu generieren fand ich damals seltsam.
Naja, vor AJAX gab es nicht allzu viele andere Möglichkeiten. Ich persönlich fand jedoch ganz andere Dinge an PHP problematisch: die konzeptionelle Vermischung von HTML und PHP, die Objektorientierung von Java mit Zugriffsmodifikatoren und keine Namensräume... Aber bitte, können wir uns hier bitte auf die Sicherheitslücken konzentrieren?
Hab mir dann was in Perl geschrieben,
Für Perl gab es übrigens etwas konstruktiv ganz Ähnliches, weiland "embperl" genannt. Das kennt heute (aus sehr guten Gründen) kaum noch jemand, auch wenn zuletzt im November 2023 die Version 3.0 davon erschienen ist. :-)
Ich glaube, gruselig ist die Situation eher, weil so viele scheinbar
professionelle Anwendungen auf Hobbyprojekten von Leuten basieren, die
das ganze völlig unprofessionell machen.
Einige, aber leider nicht alle, und nicht jeder hängt dauerhaft am Nachrichtenstrom der Medien. Und wie oben schon erwähnt, halte ich es angesichts des enormen Gefahrenpotentials der genannten Sicherheitslücken für besser, die Meldung mehrmals zu lesen, als sie einmal verpaßt zu haben.
Wenn ich allerdings lese, daß das PHP-Team schon seit zwei Jahren an
einer dieser Sicherheitslücken herum gedoktort hat, sie also schon
mindestens so lange bekannt war, finde ich das schon echt gruselig.
Ich glaube, gruselig ist die Situation eher, weil so viele scheinbar
professionelle Anwendungen auf Hobbyprojekten von Leuten basieren, die
das ganze völlig unprofessionell machen.
Die genannten Sicherheitslücken betreffen jedoch leider auch PHP-Anwendungen, die mit professionellem Anspruch und aller gebotenen Sorgfalt entwickelt worden sind. Wenn Du grundsätzlich über PHP lästern möchtest, eröffne bitte einen eigenen Thread dazu, und darin rante ich dann vielleicht sogar mit. :-)
Es gibt die Sprache PHP.
Dann gibt es einen Interpreter, der den Code bekommt, Bytecode baut und ausführt.
Der Fehler/Sicherheitslücke ist aber nicht in der Sprache PHP, sondern im Interpreter, richtig?
Es gibt nämlich auch andere PHP Interpreter als den von php.net. Es gibt sogar einen in Rust geschriebenen PHP Interpreter. Und weil Rust eine Memory-safe Sprache ist, gibt es die php2shell-Lücke in diesem Interpreter nicht.
Ich bin nur etwas verwirrt weil in den Nachrichten immer von einer Lücke in der Sprache PHP gesprochen wird. So als hätte die Sprache HTML eine Lücke, nur weil einer der Interpreter dafür, Internetexplorer, bei manchem HTML Code zu Sicherheitsproblemen führt.
weil in den Nachrichten immer von einer Lücke in der Sprache PHP
gesprochen wird
Nachrichtenmacher sind auch nicht vom Fach, genau so wie viele von uns auch (Mich eingeschlossen. Ich kann zwar ein wenig PHP programmieren, aber die genaue Funktionsweise von PHP kenne ich nicht).
Ich glaube, gruselig ist die Situation eher, weil so viele scheinbar
professionelle Anwendungen auf Hobbyprojekten von Leuten basieren, die
das ganze völlig unprofessionell machen.
Meinst du mit den Profis zufällig Microsoft? :)
Ach komm... die kochen doch nur mit demselben Wasser wie der ganze Rest unserer Branche.
Mich interessiert auch, welcher Seitenbetreiber nicht betroffen ist,
wenn es welche gibt.
Zum Glück sind meine Server nicht betroffen, weil da keine PHP-Software darauf läuft. Das Meiste meiner Fremdsoftware (Forgejo, Woodpecker, LeoMoon-Wiki, Traefik, Tinyauth, Caddy) wurde in Go entwickelt, LLDAP in Rust, und meine eigene Software für Kunden, Freunde und mich ebenfalls entweder in Golang oder in Python.
Insofern habe ich zwar dieses Mal Glück gehabt oder möglicherweise auch Erfolg mit meiner Strategie, PHP soweit wie möglich zu meiden. Aber das heißt doch leider nicht, daß morgen keine ähnlichen Fehler in Python, Golang, Rust oder ihren Libraries sind.
Tatsache ist, daß wir mit KI eine vergleichsweise neue Technologie haben, die Fehler in bereits vorhandenen Programmen findet. Derartige Fehler werden früher oder später einmal größtenteils gefunden und behoben sein, und die KI schon in der Entwicklung von Software zur Vermeidung von Sicherheitslücken genutzt werden, und danach wird es sicherlich auch wieder ruhiger. Aber bis dahin leben wir, um einen chinesischen Fluch zu bemühen, zuerst noch eine Weile lang in interessanten Zeiten. :-)
Der Fehler/Sicherheitslücke ist aber nicht in der Sprache PHP, sondern
im Interpreter, richtig?
Richtig.
Ich bin nur etwas verwirrt weil in den Nachrichten immer von einer Lücke
in der Sprache PHP gesprochen wird. So als hätte die Sprache HTML eine
Lücke, nur weil einer der Interpreter dafür, Internetexplorer, bei
manchem HTML Code zu Sicherheitsproblemen führt.
Das ist leider nicht ganz einfach zu erkennen. Die meisten Greenfield-Implementierungen wie RustPHP oder php-interpreter dürften wahrscheinlich immun sein. Projekte hingegen, die die C-Bindings von PHP und damit also letztlich die Zend-Engine nutzen, wie ext-php-rs, Roadrunner und FrankenPHP, sind dagegen betroffen.
weil in den Nachrichten immer von einer Lücke in der Sprache PHP
gesprochen wird
Nachrichtenmacher sind auch nicht vom Fach, genau so wie viele von uns
auch (Mich eingeschlossen. Ich kann zwar ein wenig PHP programmieren,
aber die genaue Funktionsweise von PHP kenne ich nicht).
Im Grunde genommen funktionieren alle modernen und verbreiteten Skriptspracheninterpreter ähnlich, egal ob sie PHP, Perl, Python oder Ruby heißen: zur Laufzeit wird der Quellcode in einen Bytecode (Opcodes) kompiliert und dieser dann ausgeführt (interpretiert).
Gustl hat Recht: die hier besprochenen Fehler stecken natürlich nicht in der Sprache PHP selbst, sondern in einem Interpreter für die Sprache, der als Referenzimplementierung aber besonders weit verbreitet ist.
Je verbreiteter er ist, desto interessanter wird es für die Typen Schaden anzurichten.
Eigentlich kann man nur selbst seine Fehler suchen oder Teergruben bauen, um Schädlinge zu erkennen. Damit sind die Fehler leider noch NICHT behoben.
Eigentlich kann man nur selbst seine Fehler suchen oder Teergruben
bauen, um Schädlinge zu erkennen.
Eine Teergrube wäre ja etwas, das den Angreifer möglichst lange beschäftigt und so seine Ressourcen belastet. Für die Erkennung reicht hingegen schon ein Honeypot.
Und da wärden noch die Gerätschaften, die irgendwo im Lager/im Keller liegen und die nie ein update erhalten haben und auch nie erhalten werden. Diese müssten eigentlich "entsorgt" werden.
Je verbreiteter er ist, desto interessanter wird es für die Typen
Schaden anzurichten.
Klar.
Eigentlich kann man nur selbst seine Fehler suchen oder Teergruben
bauen, um Schädlinge zu erkennen. Damit sind die Fehler leider noch
NICHT behoben.
Nun, unter Linux kann man schon ein bisschen mehr machen, etwa mit Seccomp, AppArmor, SE-Linux, Grsecurity, SMACK, Namespaces, Controlgroups, Capabilities und ACLs und sinnvollen Kombinationen dieser Technologien. Aber das braucht Kenntnisse und Fähigkeiten, die leider nicht alle Betreiber öffentlicher Webservern haben, und es kostet eine Menge Arbeit, die diese Betreiber sich erst einmal leisten (können) müssen. Und dann ist es natürlich auch immer eine Frage des Sicherheitsbewußtseins und der Sicherheitskultur. Also müssen viele Bedingungen zusammentreffen, damit so etwas gemacht wird.
Auch wieder einer, der die Nutzungsbedingungen gelesen haben will, aber nicht wirklich verstanden hat.
Nach diesen bist Du auch nur Gast in dem Forum. Du eröffnest hier als Gast nur ein neues Thema, mehr nicht. Es gibt dafür keine Sonderrechte, wie bei Orwells Farm der Tiere - "Alle Tiere sind gleich, aber manche sind gleicher"
Bezüglich unerkannter Geräte mit nicht-updatebarer Firmware -
Für die SW in einem der neuen Autos bedeutet ein nicht schließen der sicherheitskritischen Lücke das Erlöschen der Betriebserlaubnis. D.h. wenn der Hersteller nach 10J keine Updates mehr macht, kann es vorbei sein.
Mit großer Wahrscheinlichkeit wird es noch ein Angebot geben, dass für eine Zuzahlung weiterhin noch Updates durchgeführt werden, aber da werden wir abwarten müssen bis es so weit ist um zu wissen ob die Preise dafür moderat oder heftig sein werden.
Für die SW in einem der neuen Autos bedeutet ein nicht schließen der
sicherheitskritischen Lücke das Erlöschen der Betriebserlaubnis.
StVZO § 19 Erteilung und Wirksamkeit der Betriebserlaubnis:
Die Betriebserlaubnis des Fahrzeugs bleibt, wenn sie nicht ausdrücklich entzogen
wird, bis zu seiner endgültigen Außerbetriebsetzung wirksam. Sie erlischt, wenn
Änderungen vorgenommen werden, durch die ..."
Ein Software-Problem, das schon bei der Zulassung drin war, führt demzufolge nicht automatisch zum Verlust der Zulassung. Da ein Problem wie php2shell nicht erst durch eine Änderung entstand, wäre es demzufolge kein Grund für den Entzug. :)
Ein Software-Problem, das schon bei der Zulassung drin war, führt
demzufolge nicht automatisch zum Verlust der Zulassung.
Das hängt von der Kritikalität der Sicherheitslücke ab, die sich erst später herauskristalliert. Wenn diese von Hackern nur dazu benutzt werden kann, dass Dich Dein Auto mitten unter der Fahrt beleidigt, als "Du Arschloch, wir werden Dich morgen anzünden!" auf dem Display anzeigt, dann wird das nicht automatisch einen Verlust der Zulassung bewirken. Aber wenn Dein Fahrzeug übernommen werden kann um es personenschädlich verunfallen zu lassen, erfolgt das umgehend. Das steht übrigens in anderen Gesetzen und Verordnungen.
Und Du wiederum bist Gast in meinem Thread. Also schreib' zum Thema oder geh. Sonst muß wieder ein Moderator kommen und Dich entfernen, wie beim letzten Mal.
Erkläre bitte mal allen hier im Forum, inwiefern die Diskussion nichts mit Deinem Thema zu tun habe.
Wir diskutieren gerade, wenn diese oder eine ähnliche Sicherheitslücken die IT eines Autos betreffen würde, welche Konsequenzen das für ein Auto und dessen weitere Nutzbarkeit haen könnte, das ggf. droht aus dem Verkehr gezogen zu werden.
Wenn Du glaubhaft machen kannst, dass PHP auf keinem Fahrzeugcomputer läuft, auch nicht auf der IT in der gesamten IT-Produktionsschiene vom Programmierer bis zur Verteilung auf das Fahrzeug, dann wäre unsere Diskussion natürlich nicht mehr im Themenkomplex.
Wir diskutieren gerade, wenn diese oder eine ähnliche Sicherheitslücken
die IT eines Autos betreffen würde
Nein, Du brabbelst wirres Zeug, weil Du von IT keinerlei Ahnung hast, aber Dein narzisstischer Selbstdarstellungsdrang Dich trotzdem zwingt, Deinen Müll abzusondern.
auch nicht auf der IT in der gesamten IT-Produktionsschiene vom
Programmierer bis zur Verteilung auf das Fahrzeug
Dummschwätzer.
"Auf den Servern im Hintergrund (Backend) oder "Connected Cars": Automobilhersteller nutzen PHP durchaus für ihre Web-Infrastrukturen, Kundenportale, Online-Konfiguratoren oder die APIs der Smartphone-Apps. Wenn Ihr Auto "nach Hause telefoniert" (z. B. um den Ladestatus abzufragen), kommuniziert es oft mit einem Webserver, auf dem PHP läuft."
Sicher? Belege?
Hinter den Touchscreen in den Geräten meiner Firma werkeln Raspberry Pis u.a. für die Darstellung. Da läuft aber ein handgeschriebener Webserver drauf.
Wären wir faul gewesen, hätten wir vielleicht auch php benutzt.
Ich weiß ja nicht, was Tesla oder die anderen mit ihren Monsterdisplays verwenden. Du?
Zurück zum Thema.
Was erwartest du, was da noch kommen soll? Dass ausschalten und wieder einschalten nichts bringt?
Erfahrungsberichte?
Dein Eingangspost liefert die Meldung (die man sogar mitbekommen hat, wenn man die Tagesschau guckt). Und dann? Irgendwie nichts mehr.
Wenn Ihr Auto "nach Hause telefoniert" (z. B. um den Ladestatus
abzufragen), kommuniziert es oft mit einem Webserver, auf dem PHP läuft.
Konkretes Beispiel?
Und selbst wenn, mit der Betriebserlaubnis des Fahrzeugs hat das nichts zu tun. Also das übliche Dieter-Geschwätz, um nicht zuzugeben, dass Du schlichtweg keine Ahnung hast.
Und Du wiederum bist Gast in meinem Thread. Also schreib' zum Thema oder
geh.
Meiner, deiner, Thread ist für uns alle da.
Und "schreib was zum Thema?" Was denn? Das Herumheulen über die PHP Lücken? Die sind eh ein alter Hut. Du schalt lieber mal den Fernseher ab und besorge dir ein gutes C-Lern-Buch und arbeite das gut durch.
Und dann nimm bitte mal den Zeigefinger runter, denn das riecht eh schon nach Doppelmoral und Gaslighting. DAS ist übrigens auch nix neues, lol.
