> https://bugs.php.net/bug.php?id=75006 has been marked as a non-security
> bug, with the justification that unserialize() should not be fed untrusted
> input. While we do document that unserialize() shouldn't be used on
> untrusted input, we have always treated these as security bugs in the past.

Not always, but sometimes we did. I think we should stop doing it, as to
not validate the idea that unserialize can safely be used with untrusted
data (it can't, and it doesn't look likely that it ever will be, at
least not without comprehensive rewrite and possibly removing references
support, which is not likely to happen).

If anybody strongly feels that this is wrong, we can make an RFC about
it, but given the current state of unserialize(), I can not say we can
support such usage scenario in the current state of unserialize() code,
and would like to hear arguments to the contrary.

If somebody wants to do something about it, please feel welcome, we have
a number of open unserialize bugs right now (if you want to work on them
and don't have access to private bugs and you believe you should -
please ask on security@ list).

Stas Malyshev

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to