more extensive note on unserialize() change

diff --git a/UPGRADING b/UPGRADING
index 80b6fb1aa621136b5171d100c77b335862a9a442..92ed275a081d90bd2694ed23f5f551ee7ea255e0 100644 (file)
--- a/UPGRADING
+++ b/UPGRADING
@@ -10,6 +10,7 @@ PHP 5.4 UPGRADE NOTES
 2. Changes to reserved words and classes
 3. Changes to engine behavior
 4. Changes to existing functions
+   a. unserialize() change
 5. Changes to existing classes
 6. Changes to existing methods
 7. Deprecated Functionality
@@ -350,8 +351,45 @@ PHP 5.4 UPGRADE NOTES
 - Since 5.4.7, ctor is always called when new user stream wrapper object is created.
   Before, it was called only when stream_open was called.
 
-- Manipulated serialization strings for objects implementing Serializable by
-  replacing "C:" with "O:" at the start will now produce an error.
+4a. unserialize() change
+------------------------
+
+- Starting PHP 5.4.29, the bug fix for bug #67072 introduces a change to 
+  unserialize() function, detailed below:
+
+    If the string looking like 'O:..:"ClassName":...' is unserialized, and
+    the class named is an internal class that declares custom unserializer
+    function, or extends such class, unserialize would fail.
+
+    Using O: for user classes not extending internal classes (including
+    those implementing Serializable) is still supported in 5.4, though
+    it is deprecated and may not be supported in 5.6. Same for using O: for
+    internal classes implementing Serializable (like ArrayObject) and
+    classes that extend them.
+
+    The reason for that is that O: format is meant to be used with classes
+    that do not define custom handlers, and was never intended for the use
+    with classes that do. When used with the class that relies on custom
+    unserializer, it can leave the object of such internal class in an
+    inconsistent state which has been observed to result in crashes and may
+    also lead to memory corruption and ultimately even arbitrary code
+    execution. This was never the intended use of unserializer, and mere
+    possibility of doing this constitutes a bug, since the data passed to
+    unserialize() is not a valid serialization of any object. Since there
+    are many applications applying unserialize() to untrusted data, this
+    presents a potential security vulnerability. Thus, keeping such bug in
+    the code base was considered too dangerous.
+
+    We are aware that some applications use O: format as a way to
+    instantiate classes. This was never the intended usage of serializer,
+    and ReflectionClass methods such as newInstance or
+    newInstanceWithoutConstructor can be used for that. We're working on
+    providing more comprehensive solution for such use cases in PHP 5.6 and
+    welcome the ideas in this area.
+
+    We note also that using unserialize() on any data that is not the result
+    of serialize() call continues to be an unsupported scenario and should
+    not be relied on to produce any specific result.
 
 ==============================
 5. Changes to existing classes