improve exploit for more restrictive location regexp

[neex]

Currently, our exploit works only when Nginx config is like this:

location ~ [^/]\.php(/|$) {
   ...
}

I believe that far more popular config snippet is like this:

location ~ \.php$ {
   ...
}

which allows only URLs that end with .php (and not just contain .php/ somewhere).

Given location ~ \.php$, there're two further config options:

1. It includes something like try_files $uri =404 into the location section. There's nothing we can do in this case as it forbids access to non-existing files (and we need it). However, this requires php-fpm and Nginx to share their FS, and I believe many DevOps consider this not modern enough.
2. The config doesn't have any further restrictions; it passes to php-fpm all URLs that end on .php. We can win in this case as fastcgi_split_path_info is still probably here (and it doesn't matter which regexp it uses).

However, to improve our exploit for case 2, we need even shorter php.ini options. We have 23 bytes currently and after adding ;.php to every string we have only 18 left. So there's a research field.

[gl3nc4rt3r]

<?=`$_GET['a']`;
might be a payload right?

[kaylined]

Combined with XSS this could be used to get HTTPOnly cookies, such as PHP Session ID - and 1 character to spare! Can dump $_SESSION and be at 23 chars

[mehov]

However, this requires php-fpm and Nginx to share their FS, and I believe many DevOps consider this not modern enough

I can't help but ask what's modern enough then? :)

[neex]

I can't help but ask what's modern enough then? :)

I meant that it's simpler to use two different containers, one for nginx and other for php-fpm, and nginx doesn't actually needs to have access to the php files as it only proxies requests to php-fpm.

[neex]

This ticket was opened before we released the PoC in hope we'll discover a way to bypass the limitation before the issue is public. Obviously this is not such an interesting question anymore as the bug is long fixed by now. Closing.