Re: Unserialize security policy

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. -- Stas Malyshev smalyshev@gmail.com