Thema: Wieder Lücke in PHProjekt

[SiLæncer]

Die Entwickler der beliebten Open-Source Groupware-Suite PHProjekt weisen auf eine weitere kritische Sicherheitslücke hin, mit der Angreifer das System unter ihre Kontrolle bringen können. Zuletzt wurde ein kritischer Fehler in der Setup-Routine beseitigt, über den sich die Konfiguration der Installation nachträglich ohne Admin-Rechte ändern ließ. Der nun aufgedeckte Fehler in der Login-Funktion authform.inc.php erlaubt durch das Manipulieren des Parameters path_pre beliebige externe Skripte einzubinden und auszuführen. Voraussetzung ist allerdings, dass register_globals aktiviert ist. Die Lücke ist in Version 4.2.3 geschlossen.

Quelle : www.heise.de

[SiLæncer]

Das PHP-Team hat die Version 5.1 seiner Open-Source-Skriptsprache PHP veröffentlicht. Zu den interessantesten Verbesserungen gegenüber der 5.0er Version gehören die Datenbankabstraktionsschicht PHP Data Objects (PDO), eine nochmals beschleunigte Ausführungseinheit (Zend Engine II) und ein Update des PCRE-Moduls für Perl-kompatible reguläre Ausdrücke auf Version 6.2. Die PHP-Funktionsbibliothek PEAR wurde auf Version 1.4.5 gehoben. Das Changelog verrät wie gewohnt die Details aller Änderungen und Neuerungen.

Das PHP-Team empfiehlt allen Anwendern der Version 5.0.x und der 5.1er Betas ihre Installationen so schnell wie möglich auf die fertige Version 5.1 zu aktualisieren: In PHP 5.1 seien auch einige wichtige Fixes für Sicherheitslücken eingegangen. Ein Upgrade-Guide weist auf die Fallstricke hin. PHP 5.1 steht im Quellcode und als vorkompiliertes Windows-Binary zum Download bereit.

Quelle und Links : http://www.heise.de/newsticker/meldung/66624

[SiLæncer]

Die PHP-Version 5.1 blieb nur vier Tage aktuell: Am Montag gaben die PHP-Entwickler Version 5.1.1 der Skriptsprache heraus. Grund für die Hast waren heftige Auseinandersetzungen in der PHP-Gemeinde. In Release Candidate 6 von PHP 5.1 – also erst eine Woche vor der endgültigen Veröffentlichung – hatten die Entwickler eine native date-Klasse eingeführt. Wenige Stunden nach Publikation von PHP 5.1 wurde massive Kritik laut wegen Unverträglichkeiten mit der PEAR-Bibliothek date.

Der für PHP 5.1 zuständige Entwickler Ilia Alshanetsky hat seine Sicht der Ereignisse öffentlich gemacht; in seinem Blog spricht er von einem Fiasko, das bei besserer Kommunikation mit der PEAR-Group vermeidbar gewesen wäre. Das Changelog benennt auch eine Reihe von behobenen Fehlern, darunter Parsing-Fehler, wenn am Ende des Codes oder eines eval-Blocks ein Kommentar steht.

Quelle und Links : http://www.heise.de/newsticker/meldung/66745

[SiLæncer]

Das Update der Skriptsprache PHP auf 5.1.2 behebt diverse Fehler und schließt einige Sicherheitslücken seit der etwas überstürzt herausgebrachten Version 5.1.1. Neben 85 Bugfixes bringt die neue Release aber auch einige Funktionserweiterungen.

So ist die Unterstützung für die gebräuchlichen Hash-Algorithmen nun ebenso integriert wie der XMLWriter oder die Kompression des PNG-Bildformats. Oracle-Datenbanken können nun über eine neue OCI8-Erweiterung angesprochen werden. Eine vollständige Liste der Änderungen findet sich im Changelog.

Quelle und Links : http://www.heise.de/newsticker/meldung/68292

[SiLæncer]

Update
Unter anderem ist in der neuen Version auch eine Format-String-Schwachstelle in der mysqli-Erweiterung beseitigt, mit der sich Code einschleusen und ausführen lässt. Ursache des Problems ist die fehlerhafte Verarbeitung von Error-Meldungen. Laut Stefan Esser, Entdecker der Lücke, ist es allerdings nicht so einfach, manipulierte Fehlermeldungen zu übergeben. Ausgeschlossen ist es indes nicht, beispielsweise kann ein Angreifer einen MySQL-Server unter seine Kontrolle bringen und dessen Fehlermeldungen manipulieren.

Zudem berichtet Esser über eine Lücke in der Session-Extension, die sich für sogenannte HTTP-Response-Splitting-Attacken ausnutzen lässt. Dabei kann ein Angreifer eigene HTTP-Daten in die Antworten eines Servers einschleusen und etwa für Cross-Site-Scripting- und Phishing-Attacken ausnutzen.

Quelle : www.heise.de

[SiLæncer]

Nicht nur der aktuelle 5er Ast der Open-Source-Skriptsprache PHP wird gepflegt, auch der weit verbreitete 4er Ast befindet sich noch im Visier der Entwickler. Der jüngste Update auf Version 4.4.2 beugt Sicherheitsproblemen vor, etwa indem die PHP-Engine nur noch einzeilige Header zulässt und damit Angriffe per Header Injection erschwert. Außerdem haben die Entwickler ein Einfalltor für Cross-Site-Scripting-Attacken (XSS) in der Funktion für Fehlerausgaben geschlossen. Die Details der Bugfixes verrät das Changelog.

Quelle und Links : http://www.heise.de/security/news/meldung/68354

[SiLæncer]

Der Sicherheitsdienstleister Infigo hat mehrere Schwachstellen in den aktuellen PHP-Versionen gefunden, über die Angreifer aus dem Netz eine Denial-of-Service-Attacke (DoS) initiieren oder beliebigen Code ausführen könnten. Ein Heap-basierter Pufferüberlauf sowie ein DoS betreffen sowohl PHP 4.4.2 und 5.1.2, ein weiterer DoS ist nur unter PHP 5.1.2 möglich.

Die Funktion wordwrap() berechnet bei sehr langen Zeichenketten eine Integervariable falsch, da diese überlaufen kann und in Folge einen zu kleinen Wert enthält. Später fordert PHP mit diesem Wert einen Speicherpuffer an, in den die zu große Zeichenkette kopiert wird.

Übergibt ein Anwender der Funktion array_fill(int start_index, int num, mixed value) einen großen Wert für num Einträge, kann dadurch der komplette Speicher in kurzer Zeit aufgebraucht werden und so das System zum Stillstand kommen. Hierzu muss der Administrator in der php.ini jedoch einen großen Wert als memory limit konfiguriert haben.

Ausschließlich in PHP 5.1.2 kann aufgrund einer fehlerhaften Eingabeprüfung in der Funktion substr_compare(string main_str, string str, int offset [, int length [, bool case_insensitivity]]) zu einer Speicherzugriffsverletzung kommen, wenn dem Längenparameter ein Wert zugewiesen wird, der größer als die Länge der Zeichenkette abzüglich des Offsets ist.

Infigo hat seiner Sicherheitsmeldung zufolge die PHP-Entwickler mehrmals seit dem 2. März kontaktiert, jedoch keine Rückmeldung von ihnen erhalten. Daher stehen für die Schwachstellen noch keine Patches bereit.

Siehe dazu auch:

    * Multiple PHP4/PHP5 vulnerabilities, Sicherheitsmeldung von Infigo
    * Download der aktuellen PHP-Versionen

Quelle und Links : http://www.heise.de/security/news/meldung/72330

[SiLæncer]

Seit einigen Tagen stellen verschiedene Provider einen deutlichen Anstieg gehackter Kundenpräsenzen ("Defacements") und installierter Hintertüren auf vielen Webservern fest.

Die offenbar zielstrebig vorgehenden Angreifer nutzen dabei eine Vielzahl bekannter Sicherheitslücken aus, die zwar größtenteils nicht neu und auf fachkundig administrierten Servern in der Regel auch abgesichert und deaktiviert sind. Dabei ist vor allem vor den Auswirkungen der PHP-Funktionen popen() und proc_open() zu warnen, die bislang ein unbekanntes Schattendasein führten.

In den Angriffen der vergangenen Tage wurden diese Funktionen gezielt ausgenutzt, ermöglichen sie doch ebenfalls den Start lokaler Shell-Kommandos auf dem Server. Sichert eine Webseite die Nutzung dieser Funktionen nicht richtig ab, kann ein Angreifer damit eigene Kommandos ausführen oder gar eigene Hintertüren installieren. Beim Einsatz sogenannter Bots verbinden sich diese mit IRC-Servern, um Kommandos des Angreifers entgegenzunehmen. Die so infizierten Server lassen sich damit flexibel zu beliebigen Aktionen missbrauchen.

Zugriffe auf das Dateisystem eines Webservers sind allgemein ein großes Problem und werden fachkundig mittels open_basedir abgesichert. Der Start von Shell-Kommandos in PHP-Scripts ermöglicht es Angreifern, diese Beschränkungen zu umgehen, sodass sie Leserechte auf weite Teile des Dateisystems erhalten: Außer Systemdateien des /etc-Verzeichnisses sind auch temporäre Dateien mit Session-Informationen fremder Nutzer einsehbar. Von anderen Webpräsenzen auf demselben Server sind die Passwörter der .htpasswd-Dateien beziehungsweise MySQL-Zugangsdaten einsehbar.

Pikanterweise sind die Probleme nicht neu. Anders als bei system() und exec() hat das PHP-Team es jedoch in der Vergangenheit versäumt vor popen() und proc_open() ausreichend zu warnen. Auf den Handbuchseiten der jeweiligen Funktionen finden sich keine Warnungen, auch bei der Besprechung verschiedener Sicherheitsstrategien im Manual des PHP-Projektes werden system(), exec() oder phpinfo() erwähnt -- der Verweis auf proc_open() und popen() fehlt aber in aller Regel.

Aufgrund der geringen Bekanntheit haben nur wenige Hobby-Programmierer bislang diese Fuktionen benutzt, allerdings kommen sie zum Beispiel bei den weit verbreiteten Projekten mediaWiki und eGroupware zum Einsatz. Nach ersten Tests scheint eine Deaktivierung von popen() allerdings nur geringe Auswirkungen auf die Funktion dieser Programme zu haben, grundsätzlich bleiben sie lauffähig.

Sofern Programmierer saubere Eingabevalidierung betreiben und popen()-Aufrufe nur mit sicheren Parametern benutzen, droht dem Webserver keine Gefahr eines Angriffes von auflen. Verarbeiten Programmierer jedoch ungefiltert Nutzereingaben in diesen Funktionsaufrufen, können Angreifer beliebige eigene Kommandos einschleusen, wie jüngst beim CMS open-medium geschehen. Nicht zuletzt könnten Angreifer gezielt versuchen, sich einen Account bei einem Provider zu besorgen, um eigenen PHP-Code bequem selbst hochzuladen.

Administratoren sollten also versuchen, diese Funktionsaufrufe durch den Eintrag

disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open

in der Datei php.ini zu verbieten, müssen dann jedoch kritisch beobachten, ob Funktionsstörungen bei Kundenpräsenzen auftreten.

Das frei verfügbare AppArmor mit dem Apache-Modul mod_changehat könnte eine Lösung sein: Es ermöglicht es, für einzelne Webpräsenzen verschiedene AppArmor-Profile zu übergeben, die den Dateizugriff auch bei externen Programmaufrufen kontrollieren können.

Quelle und Links : http://www.heise.de/security/news/meldung/73837

[SiLæncer]

Die neue PHP-Version 4.4.3 beseitigt neben 20 unkritischen Fehlern auch einige seit mehreren Monaten offenen Sicherheitslücken. Unter anderem ließ sich in der Funktion wordwrap() ein Buffer Overflow provozieren. Ob darüber das Einschleusen und Ausführen von Code möglichwar, geben die Entwickler nicht an. Des Weiteren wurden Schwachstellen in den Funktionen tempnam() und phpinfo() beseitigt, die in PHP 5 seit Version 5.1.3 vom Anfang Mai bereinigt sind – bekannt sind sie sogar seit Mitte April 2006.

Dass sich die Entwickler mit den Fixes so viel Zeit gelassen ließen, ist unerfreulich. Immerhin ermöglicht die Lücke in phpinfo() das Einschleusen von JavaScript in den Browser eines Opfers, mit denen Angreifer beispielsweise Cookies der Anwender auslesen können. Durch den Fehler in tempname() ließ sich die open_basedir-Zugriffsbeschränkung, eine Alternative zum Safe Mode, austricksen, die ein Ausbrechen des Anwenders aus seinem Heimatverzeichnis verhindern soll. Auch der Buffer Overflow in wordwrap() ist seit April bekannt. Allerdings wird PHP 4 auch nicht mehr weiterentwickelt. Sicherheitsupdates gibt es jedoch weiterhin – wenn auch offenbar mit erheblicher Verzögerung.

Darüber hinaus wurde der Safe_mode-Check für die error_log()-Funktion verbessert und die Parameterprüfung in substr_compare() sicherer gemacht. Die PCRE-Bibliothek (Perl Compatible Regular Expressions) zur Auswertung von regulären Ausdrücken wurde in PHP 4.4.3 auf Version 6.6 aktualisiert. Die Entwickler empfehlen das Update so bald wie möglich zu installieren. Anwender sollten aber abwägen, ob der vollständige Wechsel auf PHP 5 nicht sinnvoller ist.

Siehe dazu auch:

    * PHP 4.4.3, Release Announcement von php.net

Quelle und Links : http://www.heise.de/security/news/meldung/76388

[SiLæncer]

Die Entwickler von PHP stopfen mit den neuen Versionen 4.4.4 und 5.1.5 Sicherheitslecks in der Skriptsprache. Angreifer können die Lücken ausnutzen, um Denial-of-Service-Angriffe gegen verwundbare Systeme zu starten oder beliebige bösartige Software einzuschleusen.

Mit den neuen Versionen rüsten die Entwickler eine fehlende Überprüfung des safe_mode/open_basedir in den Funktionen error_log(), file_exists(), imap_open() und imap_reopen() nach. Weiterhin beheben sie Überläufe in den Funktionen str_repeat() und wordwrap() auf 64-bittigen Systemen. In allen Versionen kann in der GD-Erweiterung ein Überlauf auftreten. Bei der cURL-Erweiterung können Angreifer die Restriktionen des open_basedir/safe_mode umgehen, in den 5er-Versionen von PHP betrifft der Fehler auch den realpath-Cache.

Die Funktion sscanf() enthält ebenfalls einen Puffer, der überlaufen kann. Auch mit der Version 5.1.5 ist ein Lesezugriff außerhalb der Speichergrenzen in stripos(). Auf 64-Bit-Systemen beheben die PHP-Programmierer Fehler bei der Berücksichtigung von memory_limit.

Die behobenen Fehler werden wohl schon bald von Angreifern ausgenutzt. Daher sollten Nutzer von PHP unter Windows umgehend die bereitgestellten neuen Versionen einspielen. Die Linux-Distributoren werden in Kürze wahrscheinlich ebenfalls neue Pakete ausliefern. Wer nicht so lange warten mag, kann PHP mit den aktualisierten Quellcode-Paketen von der PHP-Seite selber kompilieren.

Siehe dazu auch:

    * PHP 5.1.5 Release Announcement, Ankündigung der PHP-Entwickler
    * PHP 4.4.4 Release Announcement, Ankündigung der PHP-Entwickler
    * Download der neuen PHP-Quelltexte sowie der Windows-Installer

Quelle und Links : http://www.heise.de/newsticker/meldung/76976

[SiLæncer]

Eine Schwachstelle in den aktuellen PHP-Versionen erlaubt Angreifern, Sicherheitseinstellungen zu umgehen. Das Problem kann auftreten, wenn PHP als Apache-Modul eingesetzt wird, was häufig in Shared-Hosting-Umgebungen der Fall ist.

Die Systemeinstellungen mit php_admin_value aus der php.ini lassen sich üblicherweise nicht durch Apache-Konfigurationsdateien wie .htaccess überschreiben. Läuft PHP als Apache-Modul, kann der Administrator jedoch in der Apache-Konfiguration von der php.ini abweichende Werte einstellen. In den aktuellen PHP-Versionen 5.1.6 und 4.4.4 sowie möglicherweise älteren ist es Angreifern durch einen Fehler möglich, mit der Funktion ini_restore() den Variablenwert aus der php.ini wiederherzustellen.

Die bei Shared-Hosting-Unternehmen sehr häufig anzutreffende PHP-Konfiguration setzt in der php.ini die Standardwerte für safe_mode auf off und für open_basedir keinen Wert. Meist werden erst in der Apache-Konfiguration für die virtuellen Hosts die korrekten Werte gesetzt. Die Schwachstelle öffnet für Schädlinge, die über Lücken in PHP-Skripten in das System eindringen, Tür und Tor, um weitergehenden Schaden am System anzurichten.

Laut dem Entdecker der Lücke, Maksymilian Arciemowicz, ist der Fehler in den PHP-Quellen des Versionsverwaltungssystems schon behoben. Wann eine fehlerbereinigte PHP-Version erscheinen wird, ist jedoch noch unklar.

Siehe dazu auch:

    * PHP 5.1.6 / 4.4.4 Critical php_admin* bypass by ini_restore(), Sicherheitsmeldung von Maksymilian Arciemowicz

Quelle und Links : http://www.heise.de/security/news/meldung/78010

[SiLæncer]

Die PHP-Entwickler haben die Version 4.4.6 der Skriptsprache veröffentlicht, die einige Fehler ausbügelt, die erst mit der Vorgängerversion Einzug hielten. Währenddessen melden die Initiatoren des Month of PHP Bugs (MOPB) neue Lücken, die teilweise noch nicht behoben sind.

Die Version 4.4.5 von PHP sollte einige Sicherheitslücken schließen. Allerdings führte ein Programmierfehler dazu, dass PHP bei aktiviertem register_globals abstürzen konnte. Diesen Fehler und noch einige weitere als minder schwerwiegend eingestufte Fehler, die zu Abstürzen führen konnten, haben die Entwickler darin behoben.

Beim Month of PHP Bugs sind inzwischen fünf Fehlermeldungen aufgelaufen. Neben der bereits gemeldeten Schwachstelle durch nur 16 Bit breite Referenzzähler für Variablen in PHP 4 steht nun ein Bericht über bereits bekannte PHP-Abstürze durch zu tiefe Rekursion online, die sämtliche PHP-Versionen betrifft. Etwa bei der rekursiven Überprüfung von Benutzereingaben kann PHP sämtlichen Speicher aufbrauchen, was zum Absturz führt – die PHP-Entwickler sehen darin jedoch keine Sicherheitslücke und wollen das Problem daher nicht beseitigen.

Die dritte gemeldete Lücke behandelt denselben Fehler, der sich jedoch auch in der Zend-Engine findet und darin ebenfalls aus den gleichen Gründen nicht geschlossen werden soll. Schwachstelle Nummer vier zeigt auf, dass Angreifer die als nur lokal ausnutzbar eingestufte Lücke durch den 16 Bit breiten Referenzzähler für Variablen in PHP 4 auch aus dem Netz ausnutzen können. So kann beispielsweise durch den Einsatz der Funktion unserialize() zur Überprüfung von Benutzereingaben eingeschmuggelter Schadcode zur Ausführung kommen. Die PHP-Entwickler haben diese Schwachstelle mit PHP 4.4.5 bereits behoben, allerdings eine Erwähnung in den Releasenotes vergessen.

Die letzte gemeldete Schwachstelle betraf die Funktion zend_hash_init(), die auf 64-Bit-Systemen in eine Endlosschleife geraten konnte. Der Fehler betraf alle PHP-Versionen, wurde aber bereits in PHP 4.4.5 und 5.2.1 behoben. Zwar hatten die PHP-Entwickler die zum Fehler führenden Variablen von 32 Bit Länge auf 64 Bit umgestellt, in der Zend-Engine kamen jedoch immer noch 32-Bit-Variablen zum Einsatz.

Auf Anfrage von heise Security bei Stefan Esser erläuterte dieser, dass einige bereits behobene Fehler deshalb beim MOPB auftauchen, weil die Initiatoren viele Schwachstellen schon vorab an die PHP-Entwickler gemeldet haben. Außerdem möchte der MOPB auch darauf hinweisen, dass einige als nur lokal ausnutzbar eingestufte Lücken dazu dienen können, Server über das Internet zum Absturz zu bringen.

Die MOPB-Initiatoren verweisen weiterhin auf die Projekte Hardened PHP und Suhosin, die viele der Schwachstellen in PHP beseitigen. Die Suhosin-Erweiterung soll dabei weitestmögliche Anwendungskompatibilität bieten.

Siehe dazu auch:

    * Ankündigung von PHP 4.4.6
    * Download der neuen PHP-Version
    * PHP Executor Deep Recursion Stack Overflow, Fehlermeldung beim MOPB
    * PHP Variable Destructor Deep Recursion Stack Overflow, Fehlermeldung beim MOPB
    * PHP 4 unserialize() ZVAL Reference Counter Overflow, Fehlermeldung beim MOPB
    * PHP unserialize() 64 bit Array Creation Denial of Service Vulnerability, Fehlermeldung beim MOPB

Quelle und Links : http://www.heise.de/security/news/meldung/86107

[SiLæncer]

PHP 5.2.2 und 4.4.7 stehen zum Download bereit. In beiden Versionen wurden zahlreiche Sicherheitslücken geschlossen, die teilweise im Rahmen des Month of PHP Bugs aufgedeckt wurden. Allein Version 5.2.2 weist im Changelog 15 Einträge zu Schwachstellen auf, in Version 4.4.7 sind dies immerhin noch 11.

Die meisten geschlossenen Sicherheitslücken ließen sich nur lokal ausnutzen, was aber insbesondere Nutzer von Shared Webspace in Gefahr brachte. Eine Lücke in der Verabeitung von XML-RPC-Request soll sich aber auch aus der Ferne ausnutzen lassen, um einen Server zu kompromittieren. Diese ist nun auch in beiden Versionen geschlossen.

Darüber hinaus wurden viele nicht sicherheitsrelevante Fehler behoben und mehrere Verbesserungen hinzugefügt. Ubuntu und Debian haben bereits neue PHP-Pakete zur Verfügung gestellt, die anderen Distributoren dürften demnächst nachziehen. Anwender sollten so bald wie möglich auf die neuen Versionen wechseln oder die Pakete einspielen.

Siehe dazu auch:

    * PHP 4.4.7 Release Announcement, Meldung auf php.net
    * PHP 5 ChangeLog, Meldung auf php.net
    * PHP5 vulnerabilities, Meldung auf Ubuntu
    * New php5 packages fix several vulnerabilities, Fehlerbericht von Debian
    * New php4 packages fix several vulnerabilities, Fehlerbericht von Debian


Quelle und Links : http://www.heise.de/security/news/meldung/89253

[SiLæncer]

Die Anfang des Monats erschienene PHP-Version 5.2.3 sollte zwar eine Sicherheitslücke in der Funktion chunk_split() beseitigen, nach Angaben des PHP-Sicherheitsspezialisten und Mit-Initiator des Month of PHP Bugs Stefan Esser ist dies aber nicht der Fall. Laut Esser war der ursprüngliche Fix nicht nur kaputt, sondern auch mehr oder minder Blödsinn, da das eigentliche Problem, ein Integer Overflow, nur in eine andere Zeile verschoben wurde. Aufgrund dessen wurde nun ein weiterer Fix entwickelt, der das Problem endgültig beheben soll -- allerdings bislang offiziell nur im CVS von PHP.

Esser spekuliert darüber, ob die ursprünglichen Entdecker der Lücke oder die Linux-Distributoren die PHP-Entwickler auf das Problem aufmerksam gemacht haben könnten. Immerhin würden die Linux-Distributoren mit ihren Regression Tests, also dem Testen auf Funktion und dem Wiedereinschleichen alter Fehler, zuverlässige Arbeit liefern. Der Fehler in chunk_split() führt zu einem Heap Overflow, was im günstigsten Fall zu einem Absturz des PHP-Prozesse führt. Möglicherweise lässt sich darüber auch Code einschleusen und ausführen.

Quelle : www.heise.de

[SiLæncer]

Die Entwickler der Skriptsprache PHP haben die Version 4.4.8 veröffentlicht, die mehrere Sicherheitslücken schließt und für höhere Stabilität sorgen soll. Die weitere Entwicklungsarbeit und der Support für PHP 4 wurde zum 31. Dezember 2007 eingestellt, Version 4.4.8 soll das letzte "normale" Release sein. Sofern es notwendig sei, wolle man allenfalls bis zum 8. August 2008 noch Security Releases herausgeben.

Unter anderem wurden in Version 4.4.8 Integer Overflows in den Funktion chunk_split(), strcspn() und strspn() beseitigt. Zudem ist es in der neuen Fassung nicht mehr möglich, einen bestimmten Fehler in der Funktion glob() auszunutzen, um mögliche Beschränkungen durch durch die open_basedir-Funktion zu umgehen. Dies ist nun auch mit bestimmten SQL-Queries nicht mehr möglich. Des Weiteren wurde ein Fix für einen im Rahmen des Month of PHP Bugs (MOPB) veröffentlichten Fehler überarbeitet. Ein anderer MOPB-Fehler wurde jetzt erst geschlossen, in dem sich das Verschachteln von Eingabevariablen durch die neue PHP-Option "max_input_nesting_level" begrenzen lässt.

Die Entwickler empfehlen betroffenen Anwendern zwar, so schnell wie möglich auf die Version 4.4.8 zu updaten. Allerdings empfehlen sie gleichzeitig, einen Wechsel auf PHP 5.2 zu erwägen. Nicht immer liegt dies aber in der Entscheidung des Anwenders, etwa wenn er auf ein Shared-Hosting-Angebot zurückgreift und der Hoster aus bestimmten Gründen nur PHP4 anbietet.

Quelle : www.heise.de