On Wed, Apr 17, 2019 at 12:44 AM Stanislav Malyshev <smalys...@gmail.com> wrote:
> Hi! > > > 2. Improve caller control on unserialization. Change the signature to > > public Phar::getMetadata ( mixed $allowed_classes = true ) : mixed, and > > invoke the behavior similar to how unserialize itself works. Since all > > of this problem stems from the use of untrusted content on the phar:// > > stream, we should put into the caller's hands as much control as > possible. > > This, unfortunately, is only a partial solution. As long as > serialization format supports references - and they are likely not going > anywhere - it won't be security, it's virtually impossible to secure > code that can modify references while object is being unserialized. At > least without rewriting whole unserialization code. If somebody > undertakes this task, then yes, maybe it can be made secure (not sure > even then). For now, unserializing insecure data is insecure, regardless > of allowed_classes. Allowed_classes is just a barrier to block most > obvious attacks in the wild now, but it does not guarantee safety. > This issue had an extant report, bug # 76774 [1]. To that report, I've added some detail. I agree that $allowed_classes is a partial fix. But is it not better to incrementally add defensive layers? I'll get to the immediate mitigation after I finish my phar fuzzing work, unless somebody beats me to it. bishop [1]: https://bugs.php.net/bug.php?id=76774
