Security Audit Priorities View as Markdown

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

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

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

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

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