Re: Unserialize security policy

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/