[wp-trac] [WordPress Trac] #53295: Serialized data should be handled as an opaque value
WordPress Trac
noreply at wordpress.org
Sat Jun 5 14:55:44 UTC 2021
#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
More information about the wp-trac
mailing list