Everything

php

Home » Project » Newsgroups » php.internals » Security Audit Priorities »

Security Audit Priorities

php.internals

Derick Rethans

2 years ago

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

Hans Henrik Bergan

2 years ago

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 <derick@php.net> wrote:

Tim Düsterhus

2 years ago

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

Niels Dossche

2 years ago

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

Stas Malyshev

2 years ago

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

Robert Landers

2 years ago

On Mon, Sep 25, 2023 at 10:49 AM Derick Rethans <derick@php.net> 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

Pierre Joye

2 years ago

Hello,

On Mon, Sep 25, 2023, 3:49 PM Derick Rethans <derick@php.net> wrote:

> .
>
> 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

Dusk

2 years ago

On Sep 25, 2023, at 01:49, Derick Rethans <derick@php.net> 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