Edit report at https://bugs.php.net/bug.php?id=75054&edit=1
ID: 75054
Comment by: l dot wei at ntu dot edu dot sg
Reported by: varsleak at gmail dot com
Summary: A Denial of Service Vulnerability was found when
performing deserialization
Status: Open
Type: Bug
Package: Variables related
Operating System: Ubuntu 16.40 x64
PHP Version: 7.1.8
Block user comment: N
Private report: N
New Comment:
Thanks for the link and clarification.
"Treating unserialize issues as security creates the false sense that we expect it to be
secure, when we absolutely don't." - Zeev Suraski
This interesting... Treating such issues as non-security would also create the false sense that - we
expect it to be secure now because we just updated a warning box in the documentation - nevertheless
unsafe legacy code stays the same.
CVE assignment is a mechanism to keep track of issues and keep users updated, so they are aware of
potential issues. They are not there just to make developers feel bad about the code or whatsoever.
As was done in the Facebook HHVM fork, they have changed the more risky wddx_deserialize() code from
native C/++ to PHP/HH, this IMHO is more helpful than dismissing a whole class of memory bugs as
non-issues.
Previous Comments:
------------------------------------------------------------------------
[2017-08-10 09:00:05] nikic@php.net
For context, please see this recent discussion on the PHP internals list: https://externals.io/message/100147
The situation is basically that given the current serialization format, it is unlikely that
unserialize() will EVER be suitable for use on untrusted input. There are some very fundamental
issues which are getting papered over as new bug reports come in, but the real issue is in the
format itself -- without changing the format, it appears to be impossible to make unserialize()
fully secure.
This is why there is a big red box in the unserialize() documentation: http://php.net/unserialize
------------------------------------------------------------------------
[2017-08-10 07:42:56] l dot wei at ntu dot edu dot sg
Simply dismiss these issues by suggesting a "best practice" does not seem to improve the
situation in systems built on the unsafe deserialization APIs. If deprecating them is too costly for
compatibility, maybe fixing such issues as soon as they get reported is the best way to go ? Just
two cents.
------------------------------------------------------------------------
[2017-08-10 06:29:27] spam2 at rhsoft dot net
you simply MUST NOT use serialize / unserialize for data coming from outside, use json_encode() and
json_decode() and sanitize input data anyways
------------------------------------------------------------------------
[2017-08-10 02:46:51] yohgaki@php.net
Users are supposed to do something like this by themselves.
https://wiki.php.net/rfc/secure_serialization
------------------------------------------------------------------------
[2017-08-10 02:14:43] varsleak at gmail dot com
What kind of input is considered trust?
Are ordinary php code or other applications (like WAF) doing checkup?
These input data hackers are able to control,
I do not understand why the issus can not be considered a security issue.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=75054
--
Edit this bug report at https://bugs.php.net/bug.php?id=75054&edit=1