# Security Audit Priorities - Thread: https://externals.io/message/121135 - Original archive: https://news-web.php.net/php.internals/121135 - Started by Derick Rethans on 2023-09-25T08:49:42+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #121135 — Derick Rethans — 2023-09-25T08:49:42+00:00 URL: https://externals.io/message/121135#121135 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 --- ## #121137 — Hans Henrik Bergan — 2023-09-25T13:13:24+00:00 URL: https://externals.io/message/121135#121137 · In reply to: #121135 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 > > 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 > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #121138 — tim@bastelstu.be — 2023-09-25T15:33:00+00:00 URL: https://externals.io/message/121135#121138 · In reply to: #121135 Hi > 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 --- ## #121145 — Robert Landers — 2023-09-26T09:42:50+00:00 URL: https://externals.io/message/121135#121145 · In reply to: #121135 > > 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 > > -- > > 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 --- ## #121154 — Niels Dossche — 2023-09-27T15:58:15+00:00 URL: https://externals.io/message/121135#121154 · In reply to: #121138 Hi > Hi > > > > […] > > 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 --- ## #121155 — Stanislav Malyshev — 2023-09-27T17:10:47+00:00 URL: https://externals.io/message/121135#121155 · In reply to: #121154 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 smalyshev@gmail.com --- ## #121197 — Pierre Joye — 2023-10-01T03:39:53+00:00 URL: https://externals.io/message/121135#121197 · In reply to: #121135 Hello, > . > > 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. > thanks for the feedback request :) the sapi in general (and the underlying used APIs, like http headers you mentioned) would be on top on my mind. The embedded sapi may take more importance soon I think. It won't be as wide as fpm but frankenphp (or similar) will see a significant increase in usage, for good reasons:) best, Pierre --- ## #121198 — Dusk — 2023-10-01T04:46:02+00:00 URL: https://externals.io/message/121135#121198 · In reply to: #121135 > 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