"Bypass the fact that try_files resets $fastcgi_path_info" config makes the system vulnerable again?

[mehov]

Hi,

Thank you for sharing the vulnerability! I have a quick yes-or-no question.

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

2. No file existence checks like try_files $uri =404 or if (-f $uri). If Nginx drops requests to non-existing scripts before FastCGI forwarding, our requests never reach php-fpm. Adding this is also the easiest way to patch. source

My config, copied from the default Ubuntu one, contains these lines:

# regex to split $uri to $fastcgi_script_name and $fastcgi_path
fastcgi_split_path_info ^(.+\.php)(/.+)$;

# Check that the PHP script exists before passing it
try_files $fastcgi_script_name =404;

# Bypass the fact that try_files resets $fastcgi_path_info
# see: http://trac.nginx.org/nginx/ticket/321
set $path_info $fastcgi_path_info;
fastcgi_param PATH_INFO $path_info;

So right after it performs the try_files check, it restores the PATH_INFO - does that make it vulnerable again?

[neex]

I don't think so.

The problem is that because of the \n in the URL, fastcgi_split_path_info won't split anything. Thus fastcgi_script_name will contain the full URI path, including \n when try_files is executed. Such a file obviously won't exist, so try_files check will terminate the processing of the request, and the next directive will never be reached.

[mehov]

Thanks for sharing and answering! :)