Hi, Thanks for responding to this issue.
Will calling getMetaData still parse and execute malicious code? ;__ Raymond On Sun, 14 Apr 2019, 4:47 PM Stanislav Malyshev, <smalys...@gmail.com> wrote: > 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 >
