[wp-trac] [WordPress Trac] #53295: Serialized data should be handled as an opaque value

[WordPress Trac]

#53295: Serialized data should be handled as an opaque value
-----------------------------+------------------------------
 Reporter:  whitewinterwolf  |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:
-----------------------------+------------------------------

Comment (by whitewinterwolf):

 Replying to [comment:12 siliconforks]:
 > Ultimately, the problem is that supporting such third-party tools
 requires changing the serialization format recognized by WordPress, and I
 don't think it is possible to do that without introducing a new
 vulnerability.  This is why
 "[https://core.trac.wordpress.org/ticket/17375#comment:37 `is_serialized`
 is frozen in time]".

 I'm not sure to exactly understand what you mean:

 **A)** The `allowed_classes` filter has been added to the `unserialize()`
 function by the PHP team with the sole goal to prevent any possibility of
 malicious code execution triggered by the deserialization process (see
 [https://wiki.php.net/rfc/secure_unserialize secure unserialize]). Do you
 mean that they failed their attempt and that calling `unserialized($data,
 ['allowed_classes' => false])` is still prone to unsecure deserialization
 vulnerabilities? Do you have any reference or example?

 **B)** Do you mean that the legacy and new code returns different values
 for the same serialized object data provided as input? If so, do you have
 any example?

 **C)** Do you mean that this function has been stated as ''"frozen in
 time"'', so there is by principle no point discussing any change to its
 content anyway?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/53295#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform