Nginx security advisory (CVE-2013-4547)

Server NGINX
1

Hello!

Ivan Fratric of the Google Security Team discovered a bug in nginx,
which might allow an attacker to bypass security restrictions in certain
configurations by using a specially crafted request, or might have
potential other impact (CVE-2013-4547).

Some checks on a request URI were not executed on a character following
an unescaped space character (which is invalid per HTTP protocol, but
allowed for compatibility reasons since nginx 0.8.41). One of the
results is that it was possible to bypass security restrictions like

location /protected/ {
    deny all;
}

by requesting a file as “/foo /…/protected/file” (in case of static
files, only if there is a "foo " directory with a trailing space), or to
trigger processing of a file with a trailing space in a configuration
like

location ~ \.php$ {
    fastcgi_pass ...
}

by requesting a file as “/file \0.php”.

The problem affects nginx 0.8.41 - 1.5.6.

The problem is fixed in nginx 1.5.7, 1.4.4.

Patch for the problem can be found here:

http://nginx.org/download/patch.2013.space.txt

As a temporary workaround the following configuration
can be used in each server{} block:

if ($request_uri ~ " ") {
    return 444;
}

–
Maxim D.
http://nginx.org/en/donation.html

2

Hi,

I have a question with this POC:

location /protected/ {
deny all;
}

location ~ .php$ {
fastcgi_pass …
}

These locations own different priorities,
http://nginx.org/en/docs/http/ngx_http_core_module.html#location

I think every request like “/protected/hello.php” can bypass this
security restriction like “location /protected {deny all;}”.

Is there something wrong with this POC description or something I
misunderstand? Thanks.

Regards.

yzprofile

3

Hello!

On Thu, Nov 21, 2013 at 05:15:58PM +0800, yzprofile wrote:

}

These locations own different priorities,
Module ngx_http_core_module

I think every request like “/protected/hello.php” can bypass this security
restriction like “location /protected {deny all;}”.

Is there something wrong with this POC description or something I misunderstand?
Thanks.

These are distinct examples of affected configurations.

Obviously if you have both locations in your configuration exactly as
written, access to “/protected/hello.php” is not restricted (and there
is
nothing to bypass).

This is actually a common configuration mistake to write a configuration
like this and assume that access to php files under “/protected/” is
restricted. Correct solution would be to use “^~” modifier to prevent
checking of regexp locations:

location ^~ /protected/ {
    deny all;
}

location ~ \.php$ { ... }

or using nested locations to isolate regexp locations:

location / {
    # public
    location ~ \.php$ { ... }
}

location /protected/ {
    auth_basic ...
    location ~ \.php$ { ... }
}

–
Maxim D.
http://nginx.org/en/donation.html

4

On Tue, Nov 19, 2013 at 07:02:21PM +0400, Maxim D. wrote:

Hello!

Ivan Fratric of the Google Security Team discovered a bug in nginx,
which might allow an attacker to bypass security restrictions in certain
configurations by using a specially crafted request, or might have
potential other impact (CVE-2013-4547).

I wanted to inform the list that debian has uploaded packages to handle
the issue:

nginx 1.2.1-2.2+wheezy2 for wheezy (includes the backported patch)
nginx 1.4.4-1 for sid

http://lists.debian.org/debian-security-announce/2013/msg00215.html