Announcement (2017-05-07): www.ruby-forum.com is now read-only since I
unfortunately do not have the time to support and maintain the forum any
more. Please see rubyonrails.org/community and ruby-lang.org/en/community
for other Rails- und Ruby-related community platforms.

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 Dounin
http://nginx.org/en/donation.html

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

Hello!
On Thu, Nov 21, 2013 at 05:15:58PM +0800, yzprofile wrote:
> > }>>> These locations own different priorities,http://nginx.org/en/docs/http/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 Dounin
http://nginx.org/en/donation.html

On Tue, Nov 19, 2013 at 07:02:21PM +0400, Maxim Dounin 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/2...