Re: [PHP-DEV] Security Audit Priorities
On Sep 25, 2023, at 01:49, Derick Rethans wrote: > The Foundation is organising an external audit/security check of the PHP > source code. As part of that, we would like to identify the places in > the PHP source code where checking this will have the most impact. String parsing functions. Not just for outright vulnerabilities, but also for logical errors which can make them behave differently from other implementations, or make them behave in unexpected ways when presented with unusual inputs. A couple of important examples that come to mind are: * the HTTP stream wrapper * json_encode/decode/etc * parse_url - particularly as compared to the HTML5 URL parser spec * strip_tags - similarly, compare to HTML5 tag parsing * htmlentity_decode, htmlspecialchars_decode -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Security Audit Priorities
Hi! This reminds me of something. There's an interesting paper about ReDoS resilience in different regex engines. Some programming languages, including PHP, are evaluated there and compared: https://www.usenix.org/system/files/sec22-turonova.pdf PHP has some configuration knobs for pcre (https://www.php.net/manual/en/pcre.configuration.php), not a lot to tune but maybe they can be? To be honest, I haven't looked much into this. Interesting topics, but I think not the top priority for the security audit, due to the fact that in PHP common use, regexps rarely come from a third party, and if they do (e.g. if you're writing a RE-driven search engine) you'd probably have potentially expensive searches anyway and thus make some ways to deal with it. In general, I think there are two security aspects we're dealing with - one is guarding PHP user from a hostile third party, and another is guarding PHP developer from writing the code that may expose the end user. I think the former is the higher priority, though both are ultimately important. Thanks, -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Security Audit Priorities
Hi On 25/09/2023 17:33, Tim Düsterhus wrote: > Hi > > On 9/25/23 10:49, Derick Rethans wrote: >> So, if you can suggest an area where doing an external review would have >> high impact, please reply to this email. > > Some things from top of my head in arbitrary order. Not all of them are > necessarily important themselves per se, but rather intended to spark > additional thoughts. > > - Footguns in the default configuration / tunables / php.ini [1] This reminds me of something. There's an interesting paper about ReDoS resilience in different regex engines. Some programming languages, including PHP, are evaluated there and compared: https://www.usenix.org/system/files/sec22-turonova.pdf PHP has some configuration knobs for pcre (https://www.php.net/manual/en/pcre.configuration.php), not a lot to tune but maybe they can be? To be honest, I haven't looked much into this. > - MySQL Native Driver > - password_* [1] > - hash_equals() > - ext/json, specifically json_decode() > - The CSPRNG (ext/random/csprng.c) > - bin2hex, base64_encode [2] > - Open-ended: Misuse resistance of existing functions - Is it possible for a > user to not properly check a return value and would this result in harm (i.e. > should the function throw, but does not yet)? > > Best regards > Tim Düsterhus > > [1] These tie a little into my https://wiki.php.net/rfc/bcrypt_cost_2023 RFC, > which is not code but configuration. > [2] Should these be made constant-time / should constant-time implementations > always be available? See: https://github.com/paragonie/constant_time_encoding > Cheers Niels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Security Audit Priorities
On Mon, Sep 25, 2023 at 10:49 AM Derick Rethans wrote: > > Hi, > > The Foundation is organising an external audit/security check of the PHP > source code. As part of that, we would like to identify the places in > the PHP source code where checking this will have the most impact. > > Typical areas would be where user input can be (automatically read) remotely, > such as > our RFC 1867 HTTP header parser. But we are sure there are other > important areas as well, and we would like your input. > > So, if you can suggest an area where doing an external review would have > high impact, please reply to this email. > > cheers, > Derick > > -- > https://derickrethans.nl | https://xdebug.org | https://dram.io > > Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support > Host of PHP Internals News: https://phpinternals.news > > mastodon: @derickr@phpc.social @xdebug@phpc.social > twitter: @derickr and @xdebug > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Possible the spl extension. Most of that memory lives outside of PHP during runtime and is invisible to the engine, IIRC. Lots of people put random user-input in the objects there. Robert Landers Software Engineer Utrecht NL -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Security Audit Priorities
Hi On 9/25/23 10:49, Derick Rethans wrote: So, if you can suggest an area where doing an external review would have high impact, please reply to this email. Some things from top of my head in arbitrary order. Not all of them are necessarily important themselves per se, but rather intended to spark additional thoughts. - Footguns in the default configuration / tunables / php.ini [1] - MySQL Native Driver - password_* [1] - hash_equals() - ext/json, specifically json_decode() - The CSPRNG (ext/random/csprng.c) - bin2hex, base64_encode [2] - Open-ended: Misuse resistance of existing functions - Is it possible for a user to not properly check a return value and would this result in harm (i.e. should the function throw, but does not yet)? Best regards Tim Düsterhus [1] These tie a little into my https://wiki.php.net/rfc/bcrypt_cost_2023 RFC, which is not code but configuration. [2] Should these be made constant-time / should constant-time implementations always be available? See: https://github.com/paragonie/constant_time_encoding -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Security Audit Priorities
the php-fpm master<->php-fpm worker glue code. php-fpm master usually runs as *root*, so a compromise in that glue could lead to webserver rooting On Mon, 25 Sept 2023 at 10:49, Derick Rethans wrote: > > Hi, > > The Foundation is organising an external audit/security check of the PHP > source code. As part of that, we would like to identify the places in > the PHP source code where checking this will have the most impact. > > Typical areas would be where user input can be (automatically read) remotely, > such as > our RFC 1867 HTTP header parser. But we are sure there are other > important areas as well, and we would like your input. > > So, if you can suggest an area where doing an external review would have > high impact, please reply to this email. > > cheers, > Derick > > -- > https://derickrethans.nl | https://xdebug.org | https://dram.io > > Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support > Host of PHP Internals News: https://phpinternals.news > > mastodon: @derickr@phpc.social @xdebug@phpc.social > twitter: @derickr and @xdebug > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Security Audit Priorities
Hi, The Foundation is organising an external audit/security check of the PHP source code. As part of that, we would like to identify the places in the PHP source code where checking this will have the most impact. Typical areas would be where user input can be (automatically read) remotely, such as our RFC 1867 HTTP header parser. But we are sure there are other important areas as well, and we would like your input. So, if you can suggest an area where doing an external review would have high impact, please reply to this email. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support Host of PHP Internals News: https://phpinternals.news mastodon: @derickr@phpc.social @xdebug@phpc.social twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
