Thema: PHP diverses ...

[SiLæncer]

Webanwendungen, die auf PHP beruhen und in denen Funktionen für XML-RPC zum Einsatz kommen, laufen Gefahr, geknackt zu werden. Nach Angaben des Sicherheits- und PHP-Spezialisten Stefan Esser sind in PHPXMLRPC und dessen Ableger PEAR XML_RPC Sicherheitslücken enthalten, mit denen Angreifer eigenen PHP-Code einschleusen und im Kontext des Webservers ausführen können. Gemäß der zwei von Esser veröffentlichten Advisorys ist der Fehler in den Funktionen zu finden, die XMLRPC-Anfragen und -Antworten verarbeiten.

Zentrale Rolle spielt wieder einmal die Funktion eval(), die auch bereits Anfang Juni in den genannten Modulen Löcher aufriss. Esser weist allerdings in seinen Reports darauf hin, dass die Probleme diesmal nicht von fehlerhaftem Escaping von Nutzereingaben herrühren. Stattdessen bietet diesmal die Auswertung der in Dokumenten eingebetten XML-Tags Angreifern die Gelegenheit, Schadcode auszuführen.

Zusammen mit den Entwicklern ist man das Problem angegangen und hat eine zusätzliche Prüfung der Tags eingebaut. Darüberhinaus wurden noch sämtliche eval()-Aufrufe eliminiert, um zukünftigen darauf basierenden Angriffen vorzubeugen. Die aktualisierten Versionen von PHPXMLRPC und PEAR XMP_RPC stehen zum Download bereit. Betreiber von Webapplikationen sollten in den nächsten Tagen auf Advisorys der Hersteller achten. Sehr wahrscheinlich sind zahlreiche Content-Management-Systeme und Wikis betroffen. Für das CMS Drupal ist bereits ein Security Advisory erschienen.

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

[SiLæncer]

Die weit verbreitete Skriptsprache PHP weist eine kritische Sicherheitslücke auf, die nach Einschätzung des Entdeckers Stefan Esser in vielen PHP-Applikationen von einem Angreifer übers Netz zum Ausführen von beliebigem PHP-Code genutzt werden kann. Bei einem Datei-Upload komme es unter Umständen zu einer teilweisen Überschreibung des so genannten $GLOBALS-Arrays, wodurch sich schadhafter PHP-Code an den Server übermitteln ließe. Betroffen seien unter anderem zahlreiche Applikationen, die auf der PHP-Funktionsbibliothek PEAR oder dem Forensystem vBulletin aufbauen. Die komplexen Auswirkungen dieses Problems, das auch bei register_globals=off zu Tage tritt, beschreibt Stefan Essen in einem eigenständigen Paper.

Eine weniger kritische Lücke betrifft die Funktion phpinfo(), durch die sich HTML-Code beispielsweise zum Auslesen von Domain-Cookies in die Ausgabe der Funktion einschleusen lasse. Diese Funktion sollte allerdings ohnehin nur in Testumgebungen eingesetzt werden. Als ebenfalls unkritisch wird eine Sicherheitslücke in der Funktion parse_str() eingeschätzt. So sei es unter Umständen möglich, durch Skripte, die die Funktion parse_str() mit nur einem Argument aufrufen, den PHP-Kern vorübergehend wieder in den Zustand register_globals=on zu versetzen, selbst wenn in der php.ini Gegenteiliges konfiguriert wurde.

Betroffen von den Sicherheitslücken sind alle PHP-Versionen einschließlich 4.4.0 und 5.0.5. Benutzern von PHP4 wird empfohlen, umgehend auf die neue Version 4.4.1 zu aktualisieren. Für PHP5 ist offenbar noch keine fehlerbereinigte Fassung verfügbar.

Siehe dazu auch:

    * PHP File-Upload $GLOBALS Overwrite Vulnerability, Advisory von Stefan Esser
    * $GLOBALS Overwrite and its Consequences

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

[SiLæncer]

Der Sicherheitsexperte Andreas Bogk warnt, dass die Session-ID eines an einer PHP-Anwendung angemeldeten Users trotz der jüngsten Verbesserungen in PHP nach wie vor erratbar ist. Bei genauerem Hinsehen zeigen die angeblichen Verbesserungen erschreckende Defizite auf.

Um die einzelnen Seitenabrufe einem angemeldeten User zuordnen zu können, versieht sie PHP mit einer Session-ID. Damit ein Angreifer eine Sitzung nicht mit einer gefälschten Session-ID übernehmen kann, wird diese zufällig gewählt. Fast immer, wenn auf Computern Zufallszahlen benötigt werden, kommen Pseudo-Zufallszahlengeneratoren wie der Linear Congruential Generator (LCG) zum Einsatz. Sie erzeugen durch komplexe mathematische Operationen einen Strom von Zahlen, die zumindest insoweit zufällig sind, als dass bereits erzeugte Zahlen nahezu keine Rückschlüsse auf die kommenden erlauben. Wer allerdings den Anfangszustand – also den Initialisierungswert – des Generators kennt, kann damit die gleichen Operationen durchführen und somit alle Pseudozufallszahlen berechnen.  Deshalb ist es eminent wichtig, derartige Generatoren mit wirklich nicht vorhersagbaren Zahlen zu initialisieren.

Der Hacker Samy Kamkar konnte jedoch zeigen, dass genau dies bei PHP nicht geschah und er deshalb mit einem kleinen Programm Session-IDs zumindest so weit vorhersagen konnte, dass das Ausprobieren der restlichen Möglichkeiten durchführbar wurde. Daraufhin "verbesserte" das PHP-Team die Initialisierung des LCGs so, dass dieser konkrete Angriff seit Version PHP 5.3.2 beziehungsweise 5.2.13 nicht mehr durchführbar ist. Doch wenn man sich die Änderungen im Detail anschaut, zeigen sich deutliche Schwächen. So kommentiert der Entwickler eine Änderung mit

/* Add entropy to s2 by calling gettimeofday() again */

Er ruft also als zusätzliche Zufallsquelle kurze Zeit nach dem ersten Mal ein zweites Mal die Systemzeit ab. Das lässt sich mit jemand vergleichen, der zu dem Schluss kommt, dass die Zahl X zu leicht zu erraten ist und sie darauf hin mit  X + 23 kombiniert. Wie Bogk es formuliert: "Da [wird] nicht viel mehr Entropie
hinzugefügt". Immerhin verwendet der Entwickler nur die unteren Bits der Zeitangabe.

Hinzu kommen weitere Schwächen, die Andreas Bogk in einem Advisory analysiert. Demnach bleiben nur "wenige Mikrosekunden, und die Prozess-ID" als Zufallsspender und Bogk kommt zu dem Schluss, dass sich Session-IDs nach wie vor erraten lassen. Gegen Ende legt er den PHP-Entwicklern unter anderem nahe, doch ihre Kryptographie-Kenntnisse aufzufrischen. Nicht betroffen sind übrigens PHP-Installationen, die die Erweiterung Suhosin einsetzen.

Quelle : www.heise.de

[SiLæncer]

Mit PHP 5.3.3 und 5.2.14 veröffentlicht das PHP-Team zwei Bugfixupdates der freien Scriptsprache, die diverse Sicherheitslücken schließen. Eine Änderungen in PHP 5.3 ist nicht abwärtskompatibel.
PHP 5.3.3 enthält rund 100 Bug-Fixes, darunter einige sicherheitsrelevante. Eine Änderung ist nicht abwärtskompatibel: Wurde bislang das letzte Element einer mit einem Namespace versehenen Klasse als Konstruktor behandelt, ist es nun eine normale Methode.

Beseitigt wurden diverse Speicherprobleme und weitere Lücken, die allesamt im Changelog aufgelistet sind.

Parallel wurde auch ein Update für PHP 5.2 veröffentlicht. PHP 5.2.14 ist die letzte Version für die Serie, weitere Bugfixupdates sind nicht geplant. Es ist aber durchaus möglich, dass noch Sicherheitsupdates folgen. Auch in dieser Version finden sich diverse Bugfixes und es wurden Sicherheitslücken geschlossen. Details sind dem Changelog zu entnehmen.

PHP 5.3.3 und 5.2.14 stehen unter php.net zum Download bereit.

Quelle : www.golem.de

[SiLæncer]

Ein Fehler bei der Umwandlung bestimmter Zahlen führt unter der Skriptsprache PHP zu einer Vollauslastung des Systems. So führt die Übersetzung der Zeichenkette "2.2250738585072011e-308" in eine Gleitkommazahl in der Funktion zend_strtod auf 32-Bit-Systemen zu einer Endlosschleife, in dessen Folge die CPU voll ausgelastet wird.

Betroffen sind PHP 5.2 und 5.3, allerdings offenbar nur auf Intel-CPUs, auf denen der x87-Koprozessor für die Verarbeitung von Gleitkommazahlen genutzt wird. Das x87-Design enthält einen seit längerem bekannten Fehler, der bei der rechnerischen Annäherung an eine 64-Bit-Gleitkommazahl zu dem Problem (PDF) führt. 64-Bit-Systeme nutzen standardmäßig die Befehlserweiterung SSE, bei der der Fehler nicht auftritt. Die Verarbeitung der Zahlen 0.22250738585072011e-307, 22.250738585072011e-309 und 22250738585072011e-324 soll ebenfalls in eine Endlosschleife führen.

Unter Umständen lassen sich auch Serversysteme aus der Ferne auf diese Weise aus dem Tritt bringen, dazu könnte bereits das Senden des Wertes als Parameter in einem GET-Request genügen. Die PHP-Entwicker haben den Fehler in der kommenden Version 5.3.5 beseitigt. Für Version 5.2.16 steht ein Patch im Repository bereit.

Quelle : www.heise.de

[SiLæncer]

Das PHP-Team hat zwei Updates veröffentlicht, die den jüngst bekanntgewordenen Floating-Point-Bug korrigieren.

In der eben erschienenen Version 5.3.5 der Skriptsprache PHP haben die Entwickler den Floating-Point-Bug beseitigt, der unter Umständen eine Auslastung der CPU und somit einen Denial of Service auslösen kann. Für die bereits nicht mehr offiziell gepflegte Version 5.2.x steht das Update 5.2.17 bereit.

Der Fehler wird durch die Funktion zend_strtod ausgelöst, wenn sie bestimmte 64-Bit-Gleitkommazahlen in Form von Zeichenketten zur Umwandlung in eine Gleitkommazahl an den x87-Koprozessor auf 32-Bit-Systemen weitergibt. Ein Designfehler in dem Koprozessor führt zu einer Endlosschleife und unter Umständen zu einer 100-prozentigen Auslastung der CPU. Der Fehler in x87-Koprozessoren ist schon länger bekannt.

In 64-Bit-Systemen werden die Gleitkommazahlen stets von der Befehlserweiterung SSE verarbeitet. Auf 32-Bit-Systemen müsste PHP explizit mit dem Parameter -mfpmath=sse oder mit -ffloat-store neu kompiliert werden, so die Nutzerberichte seit Bekanntwerden des Fehlers. Der Bug wird auch durch die Kennzeichnung der Zeile double aadj, aadj1, adj; mit der Erweiterung des Typqualifikator volatile im Modul zend_strtod behoben.

Laut PHP-Entwickler Johannes Schlüter ist nicht nur PHP 5 von dem Bug befallen, sondern auch alle Versionen ab PHP 3. Für ältere Versionen stellt das PHP-Team eine korrigierte Version der Funktion zend_strod zur Verfügung.

Die PHP-Versionen 5.3.5, 5.2.17 und der Patch für zend_strotd stehen auf den Servern des Projekts zum Download bereit.

Quelle : www.golem.de

[SiLæncer]

Aufgrund eines Fehlers im kürzlich veröffentlichten PHP-Release 5.3.7  raten die Entwickler von der Installation dieser Version ab und empfehlen auf die Version 5.3.8 zu warten. Ein Fehler in der Funktion crypt() führt im Zusammenhang mit dem Hash-Algorithmus MD5 dazu, dass als Ergebnis einer Hash-Operation mit Salt nur das Salt zurückgeliefert wird. Normalerweise sollte die Funktion eine Zeichenkette mit Salt und dem Hash-Wert zurückgeben.

Der Fehler kann unter Umständen dazu führen, dass bei Webanwendungen die Authentifizierung nicht mehr korrekt funktioniert. Bei den Algorithmen DES und Blowfish funktioniert crypt() weiter wie erwartet. PHP 5.3.8 soll in den nächsten Tagen erscheinen.

Quelle : www.heise.de

[SiLæncer]

Das US-CERT warnt vor einer kritischen Sicherheitslücke in PHP, die versehentlich an die Öffentlichkeit geraten ist, während die Entwickler noch an einem Fix arbeiten. Betroffen sind Server, die PHP im CGI-Modus betreiben; FastCGI-Installationen von PHP sind hingegen nicht betroffen.

Ein Team entdeckte das Problem während eines Capture-The-Flag-Wettbewerbs. Im Wesentlichen beruht es darauf, dass man dem PHP-CGI-Programm über den Aufruf spezieller URLs Kommandozeilenparameter unterjubeln kann. So sorgt etwa die URL

Code: [Auswählen]

http://localhost/index.php?-s
dafür, dass der Web-Server php-cgi mit dem Parameter -s aufruft wird, was den PHP-Quellcode von index.php als HTML ausgibt, statt ihn auszuführen. Das wäre an sich schon schlimm genug, weil PHP-Applikationen oft kritische Daten wie Zugangsdaten für Datenbanken enthalten. Doch laut den Entdeckern kann man damit auch direkt Code einschleusen und ausführen lassen, was die Lücke in die höchste Gefahrenstufe hebt.

Eigentlich sollte die Veröffentlichung der Lücke erst nach der Bereitstellung eines Patches erfolgen. Die Entdecker hatten dazu ihren Fund an das US-CERT weitergegeben, die als Vermittler agierten. Erst gestern hatte das CTF-Team zugestimmt, den PHP-Entwicklern noch etwas Zeit einzuräumen, den bereits vorhandenen Patch zu testen. Doch dann wurde der versehentlich als "öffentlich" markierte Eintrag in der PHP-Fehlerdatenbank auf der US-Site reddit gepostet und die Katze war aus dem Sack. Das CTF-Team veröffentlichte kurz danach weitere Informationen zu der PHP-Lücke in einem Blog.

Das US-CERT sieht derzeit noch keinen praktikable Möglichkeit sich zu schützen; die Entdecker der Lücke empfehlen, das PHP-CGI-Programm durch ein Wrapper-Skript zu ersetzen, das die Parameter filtert, bevor es das eigentliche PHP-Programm aufruft. Sie stellen auch ein passendes Beispiel-Skript bereit. Da das PHP-Team bereits einen Patch testet, sollte es auch bald eine offizielle Lösung für das Problem geben.

Quelle : www.heise.de

[SiLæncer]

Die am gestrigen Donnerstag veröffentlichten Updates auf die PHP-Versionen 5.3.12 und 5.4.2 sind fehlerhaft. Darauf weisen die Entdecker der Schwachstelle hin, welche eigentlich durch die Updates behoben werden sollte. Durch einen Fehler bei dem Zusammenspiel von CGI und PHP kann ein Angreifer Code auf den betroffenen Servern ausführen. Das Problem blieb acht Jahre lang unentdeckt.

Den besten Schutz bieten derzeit Filterregeln auf dem Server. Allerdings ist auch die als Workaround auf PHP.net veröffentlichte RewriteRule fehlerhaft, wie der Sicherheitsexperte Christopher Kunz berichtet. Er schlägt eine leicht abgewandelte Form der Regel als Alternative vor.

Da sich die PHP-Interpreter für CGI nicht an die Spezifikationen des CGI-Standards hält, werden URL-Parameter in bestimmten Situationen als Kommandozeilen-Parameter an PHP übergeben. Betroffen sind Server, die PHP im CGI-Modus betreiben; FastCGI-Installationen von PHP hingegen nicht. Der PHP-Patch soll dafür sorgen, dass Parameterstrings, die mit einem Minus beginnen und kein Gleichheitszeichen enthalten, ignoriert werden. Dies lässt sich jedoch nach Angaben der Entdecker der Schwachstelle einfach umgehen. Ein neuer, geringfügig modifizierter Patch wurde bereits ins Bugtracking-System eingereicht, der für einen Vergleich query_string anstelle von decoded_query_string verwendet.

Wer die Zeichenkette ?-s an das Ende einer URL hängt, kann herausfinden, ob er selbst betroffen ist. Liefert der Server PHP-Quellcode zurück, sollte man schleunigst handeln. Es ist nämlich bereits ein Metasploit-Modul im Umlauf, das auf einem verwundbaren Server eine Remote-Shell zur Ausführung beliebigen Codes öffnen soll.

Quelle : www.heise.de

[ritschibie]

Das PHP-Entwicklerteam hat einen erneuten Versuch unternommen, die kritische Schwachstelle beim Zusammenspiel mit CGI in den Griff zu bekommen. PHP interpretiert im CGI-Mode bestimmte URL-Parameter als Kommandozeilenparamter. Dadurch liefert ein betroffener Server den Quellcode einer Seite aus, wenn man die Zeichenkette ?-s an das Ende einer URL hängt (http://www.heise.de/?-s). Auch das Ausführen von Code ist auf diese Weise möglich.

Die Details zur Lücke wurden bekannt, weil die Entwickler den entsprechenden Eintrag im Bugtracking-System versehentlich als "öffentlich" markierten. Sie wird inzwischen aktiv für Angriffe ausgenutzt. Eigentlich sollte das Problem durch die Versionen 5.3.12 und 5.4.2 behoben werden, die Ende vergangener Woche erschienen sind. Es stellte sich jedoch schnell heraus, dass die Updates die Schwachstelle nur unzureichend abdichten. Offenbar gibt es weitere Möglichkeiten, die Lücke auszunutzen. Auch die anfangs als Workaround bereitgestellte Rewrite-Regel lässt sich nach Meinung von Sicherheitsexperten leicht umgehen.

Mit den jetzt veröffentlichten Versionen 5.3.13 und 5.4.3 versprechen die Entwickler erneut, die Lücke geschlossen zu haben – und ersten Tests des PHP-Experten Christopher Kunz zufolge wird das Versprechen dieses Mal auch gehalten. Darüber hinaus wurde im 5.4er-Zweig ein Buffer-Overflow behoben, der sich in der Funktion apache_request_headers befindet. Auch zu dieser Lücke findet man bereits seit Ende vergangener Woche konkrete Details im Netz. Laut dem Sicherheitsexperten Georg Wicherski handelt es sich hierbei um einen Speicherüberlauf auf dem Stack, der sich nur auf Systemen ausnutzen lässt, auf denen PHP im CGI-Mode läuft. Die Schwachstelle lässt sich unter anderen in Kombination mit dem Webserver lighttpd ausnutzen.

Einen einfachen PoC-Exploit hat er ebenfalls veröffentlicht – wohlbemerkt bereits Ende vergangener Woche. Wicherski ist über den Eintrag in der Bugtracking-Datenbank auf das Problem aufmerksam geworden. Zwar war die Lücke noch "vertraulich" markiert und die Details dadurch nicht öffentlich einsehbar, nach seinen Angaben hat ihm aber der angezeigte Name der Schwachstelle ausgereicht, um sie innerhalb von fünf Minuten im PHP-Quelltext aufzuspüren.

Quelle: www.heise.de

[SiLæncer]

Der Hacker Maksymilian Motyl hat einen Exploit veröffentlicht, der eine kritische Lücke in der aktuellen PHP-Version 5.4.3 demonstrieren soll. Die Schwachstelle befindet sich anscheinend in der Funktion com_print_typeinfo() und ist laut Motyl nur auf einem 32-bittigen Windows-System ausnutzbar. Sein Exploit soll auf dem Server eine Remote Shell öffnen, über die ein Angreifer beliebige Befehle auf dem Server ausführen kann. Weitere Details sind über die Lücke bislang nicht bekannt.

Das Internet Storm Center sieht in dem Exploit eine ernsthafte Bedrohung und empfiehlt Admins, die Datei-Upload-Funktion in sämtlichen PHP-Skripten zu deaktivieren, bis es einen Patch gibt. Zudem soll man Shellcode wie jenen aus Metasploit mit Hilfe eines Intrusion-Prevention-Systems (IPS) filtern und Buffer Overflows mittels eines IPS auf dem Host (HIPS) blockieren. Ob auch ältere PHP-Versionen betroffen sind, ist unklar. In einem Test von heise Security mit PHP-Version 5.3.10 schlug der Exploit nicht an.

Quelle : www.heise.de

[SiLæncer]

Mehrere Leser berichten über Versuche, Web-Server mit PHP zu kapern. Dabei kommt offenbar ein kürzlich veröffentlichter Exploit zum Einsatz, der eine Lücke in PHP 5 ausnutzt. Die ist zwar seit Mitte letzten Jahres bekannt und seit PHP Version 5.3.12 und 5.4.2 gefixt. Doch offenbar gibt es immer noch anfällige Server.

Der ganze Artikel

Quelle : www.heise.de

[SiLæncer]

Zum zweiten Mal im laufenden Monat veröffentlichten die PHP-Entwickler sicherheitsrelevante Patches für ihr Projekt. Allein im Versionszweig 5.6 haben sie vier Schwachstellen beseitigt.

Bereits zum zweiten Mal im Oktober gibt es sicherheitsrelevante PHP-Updates: Mit PHP 5.6.2 schließen die Entwickler vier Lücken; unter anderem einen Integer Overflow in der Funktion unserialize(), der vor rund einem Monat über das Bugtracking-System des Projekts gemeldet wurde. Er betrifft ausschließlich die 32-bit-Builds von PHP.

Der ganze Artikel

Quelle : www.heise.de

[SiLæncer]

Das PHP-Entwickerteam hat seinen Interpreter sicherer gemacht und weist darauf hin, dass der Support für Version 5.5 vor kurzem abgelaufen ist. Wer kann, sollte auf Version 5.6 umsteigen.

Das Update auf PHP 5.6.12 schließt nach Angaben des Entwicklerteams zwölf Schwachstellen; unter anderem einen Stack-Überlauf in der GD-Bibliothek. Auch die anderen Release-Zweige wurden abgesichert, hier lauten die aktuellen Versionsnummern 5.4.44, 5.5.28 und 7.0.0 Beta 3. Die Entwickler weisen darauf hin, dass der Support für den 5.5er-Zweig am 10. Juli ausgelaufen ist. Version 5.5.28 enthält deshalb nur noch Sicherheits-Patches – Bugs, die nicht sicherheitsrelevant sind, wurden hingegen nicht mehr geschlossen.

PHP 5.5 wird noch bis zum 10. Juli 2016 mit Sicherheitsupdates versorgt. Für Nutzer von PHP 5.4 wird die Luft schon am 14. September dieses Jahres dünn: Danach Termin werden die Entwickler keine weiteren Schwachstellen in diesem Release-Zweig beseitigen. Wer kann, sollte daher auf Version 5.6 umsteigen, die noch zwei Jahre mit Sicherheitsupdates versorgt wird. PHP 7 ist ausdrücklich noch nicht für den produktiven Einsatz geeignet.

Quelle : www.heise.de

[SiLæncer]

Die Macher der Skriptsprache empfehlen den Nutzern von PHP 7.0, 5.5 und 5.6 die Installation der aktuellen Security-Releases. Gleichzeitig gibt ein Blick auf GitHub und das PHP-Wiki eine Vorschau auf kommende Funktionen in PHP 7.1.

Gut einen Monat nach der Veröffentlichung von PHP 7 hat das Team mit Version 7.0.2 insgesamt 31 Bugs behoben, von denen es sechs als sicherheitsrelevant einstuft. Die vierzehn Korrekturen im PHP-Kern adressieren unter anderem zwei Speicherzugriffsfehler. Weitere Fixes beziehen sich auf den nicht sicherheitskritischen Umgang mit vorzeichenbehafteten Nullen. Das Update umfasst zudem Korrekturen für fünfzehn Module, darunter ein Speicherleck im FPM (FastCGI Process Manager).

PHP 5.6.17 behebt fünf Fehler im Kern und sechs weitere in den Modulen. PHP 5.5.31 enthält lediglich fünf Korrekturen, da sich PHP 5.5 im Security-Support-Mode befindet, also nur noch Sicherheitsupdates und keine sonstigen Fehlerkorrekturen mehr erhält.

Die vollständige Liste der behobenen Bugs steht in den Release Notes. Nutzer finden die Security Releases im Download-Bereich der offiziellen PHP-Site. Ein Blick auf GitHub zeigt zudem erste Neuerungen für PHP 7.1. Dazu gehört der in anderen Sprachen gebräuchlichen Rückgabetyp void für Funktionen, die keinen Wert zurückgeben. Außerdem dürfen nun endlich auch Konstanten innerhalb von Klassen private oder protected sein. Bisher war jede Konstante automatisch public. Die RFC-Liste (Request for Comments) für Version 7.1 befindet sich in der Wiki-Sektion der PHP-Site.

Quelle : www.heise.de