Hi,
Stanislav Malyshev wrote:
Hi!
The two main points are:
1. While it's true that if you're using unserialize() on untrusted input
you are most likely going to be vulnerable due to object injection, it may
be quite hard for an attacker to exploit this for closed source
Objects are not the problem (unless it's internal objects, in which case
the extension/code authors should have known better, but frequently
don't). References are huge problem, there are too many scenarios where
references can be made completely broken with bad serializing data.
2. We should be able to precipitate most unserialize() bugs by regularly
fuzzing it ourselves. The setup for doing so is also provided.
That assumes that problems in unserialize() stem from some accidental
errors like off-by-one here and there. I don't think it's the case - I
think that given references support, it may not be possible to make it
robust against every hostile input without completely rewriting the
whole code, and even then I'm not sure it's possible. References can
create links between unrelated data items, which may lead to very subtle
problem with semantics inside objects, etc. which current code is just
not prepared to handle.
This is roughly how I feel about the matter also.
I have wondered about whether it might be possible to rewrite
unserialize() to be somewhat more resilient to reference issues. For
example, making *every* value be unserialized as an IS_REFERENCE, rather
than retroactively replacing non-reference values with reference values,
could prevent use-after-free issues entirely. But it would also be
slower and potentially expose a lot of issues elsewhere…
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
