Hi! > I came across this article which highlights a few issues with PHP > deserialization techniques: > > https://portswigger.net/daily-swig/phar-out-php-deserialization-techniques-offer-rich-pickings-for-security-researchers
PHP serialization is not meant to be used with external or user-modifyable data. Looks like the crux of the issue is that phar uses unserialize() to read metadata, which is an insecure scenario since it is common to deal with external phar files and it's not obvious there can be serialized data. Particular Drupal exploit seems to be caused by insecure coding (one should not be able to give phar streams to system paths) but the general issue of reading phars being insecure stays. It is a bit problematic since there are no limitations in what can be stored in Phar metadata, so we can't really prohibit anything there without breaking BC. I would start with banning objects there (at least by default) but that again would be BC break if somebody did use objects there. More workable idea would be to not parse metadata unless getMetadata() is explicitly called. The chance of code that did not intend to use metadata to use this call is nil, thus eliminating the deserialization vector in most cases. OTOH, BC is kept since the metadata is still available for the code that needs it. I'll try to implement this soon. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
