
Nginx security advisory (CVE-2013-4547) - zzzcpan
http://mailman.nginx.org/pipermail/nginx-announce/2013/000125.html
======
casca
Workaround:

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

The issue is the handling of unescaped spaces. These are illegal but nginx
accepts them. The workaround is to throw an error any time someone sends the
invalid space.

~~~
ams6110
From my read it sounds like this only works if you actally have a
corresponding directory with a literal trailing space in the name (quite
uncommon, I'd think).

Or am I misunderstanding this?

~~~
est
> actally have a corresponding directory with a literal trailing space in the
> name

That would be /mydir%20/ or /%20mydir/ in URL, not literaly a space.

~~~
BobVerg
No, the vulnerability is about literal space.

~~~
est
I am replying to ams6110. Mind the context please.

> this only works if you actally have a corresponding directory with a literal
> trailing space in the name

This won't work event if you have space in name because space would actually
be %20. Only a carefully hand crafted HTTP packet would cause the
vulnerability

~~~
BobVerg
No, it won't be %20. It isn't encoded. You should mkdir or touch "name ", not
"name%20".

~~~
est
Seriously? Hello? We are talking about nginx....

~~~
BobVerg
A few quotes from the link, if you didn't read: "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)." [..] "by requesting a file as "/foo /../protected/file" (in
case of static files, only if there is a "foo " directory with a trailing
space)"

~~~
est
In case you don't read the sentence right before you quoted one:

> by using a specially crafted request.

It means you have to manually purposefully make an RFC2616 invalid HTTP
request. Period.

Which means, even for a folder name with a trailing space, normal user
wouldn't trigger this vulnerability, an attacker must use lower level
tools/libraries. For example wget will auto encode URL for you, while cURL
won't.

I tried to reply to ams6110, this vulnerability only works if you have dir
with a trailing space _and_ the attacker handcraft an http request packet,
bypassing encode and sanity checking which is required in most HTTP client
implementations.

And the vulnerability is _not_ cause by or about trailing spaces in dirs, we
can deal with those dirs fine. It's about how to make nginx config rules apply
to obscure invalid URL s. It's a pitfall in nginx rule checking engine. Are we
clear now?

~~~
BobVerg
Ok. To exploit any vulnerability the attacker have to do something. It's just
obvious. I don't understand what you're trying to make clear.

> and attacker handcraft an http request packet, bypassing encode and sanity
> checking which is required in most HTTP client implementations

Well, it's not something hard to do. You don't have to dwell on this. To talk
HTTP _you don 't even need HTTP client_ (sic!). Telnet or netcat can be easily
used instead. I usually use them while configuring web-servers, most admins
and devs usually do so.

------
staunch
A better link: [http://mailman.nginx.org/pipermail/nginx-
announce/2013/00012...](http://mailman.nginx.org/pipermail/nginx-
announce/2013/000125.html)

------
FooBarWidget
Phusion Passenger has been updated with the default Nginx version set to
1.4.4: [http://blog.phusion.nl/2013/11/19/phusion-
passenger-4-0-25-r...](http://blog.phusion.nl/2013/11/19/phusion-
passenger-4-0-25-released-upgrades-to-nginx-1-4-4-which-fixes-cve-2013-4547/)

The Phusion Passenger official APT repository has also been updated with
packages for 1.4.4:
[https://www.phusionpassenger.com/install_debian](https://www.phusionpassenger.com/install_debian)

------
nly
Call be a cynic, but isn't this why people should use parser generators
instead of handrolling this stuff?

I mean, would you want to audit this file? ->
[http://trac.nginx.org/nginx/browser/nginx/src/http/ngx_http_...](http://trac.nginx.org/nginx/browser/nginx/src/http/ngx_http_parse.c)

~~~
BobVerg
Parser generators? What's next? Java/C# instead of C?

~~~
taspeotis
[http://pragprog.com/the-pragmatic-
programmer/extracts/tips](http://pragprog.com/the-pragmatic-
programmer/extracts/tips)

    
    
        Write Code That Writes Code
        Code generators increase your productivity and help avoid duplication.

------
X4
Question to devs who've also written parsers:

Is this a lame bug?

I have never written formal verifications for code, or had to apply concepts
like "Verified Design-by-Contract", but I have written parsers, scanners and
lexers. In all honesty, the most important part of the httpd is "parsing"
requests. I have had chats with Igor, the main developer of Nginx, related to
performance tuning and the kernel TCP/IP stack. I must tell that he's a really
nice guy. But, if it was my "main job" to write a software used by millions of
people, which has an achilles heel in it's parser, then I'd sit down and teach
myself to prove the parser code. I have researched this 2y ago, and found that
you can quite professionally write BDD/TDD style tests and mocks in C99 too.
The tools available go way beyond that though.

Here's a little list of things I have found useful back then:

[http://frama-c.com/](http://frama-c.com/) (this was top notch)

[http://gulliver.eu.org/free_software_for_formal_verification](http://gulliver.eu.org/free_software_for_formal_verification)

I want to name:
[http://www.eschertech.com/products/index.php](http://www.eschertech.com/products/index.php)
and [http://research.microsoft.com/en-
us/projects/vcc/](http://research.microsoft.com/en-us/projects/vcc/) too, but
I haven't tested any of these tools, because I never worked in an environment
where my code had to go through formal verification.

~~~
zzzcpan

      > Is this a lame bug?
    

Yes, if reliability and security is your goal. But I don't think it is, so no.

~~~
X4
What is the goal of the Nginx httpd then?

~~~
zzzcpan
I guess to provide a useful web server, faster and more efficient than apache.

------
egb
Any advice on how to get PHP working after upgrading from Ubuntu default
1.1.19 to the latest from the
[http://nginx.org/en/linux_packages.html](http://nginx.org/en/linux_packages.html)
repo?

No errors thrown anywhere, but php5-fpm is dead in the water... Rolling back
until I can find anything on how to fix this.

~~~
j-kidd
Try replacing /etc/nginx/fastcgi_params with the one from
[http://wiki.nginx.org/PHPFcgiExample](http://wiki.nginx.org/PHPFcgiExample)

Also, the packaging is done differently by ubuntu and nginx upstream, so I
don't think you can just replace it. They are also bundled with different
modules. For example, I have to use the package from ubuntu because the one
from nginx upstream lacks the geoip module.

~~~
egb
Following up - this fixed it! (Took a while to get a virtualbox set up with my
old config and simulate the upgrade a few times to make sure everything was
the same)

Thanks, eh!

------
yeukhon
Will Ubuntu server gets the patch in its update? How long does it take to get
that update?

~~~
brokenparser
Given:

* nginx sits in universe rather than main

* There is no mention of a patch for this CVE in the changelogs

* No bug exists in either the Debian bug tracking system nor Launchpad for this particular bug

I'd recommend you download the source (easy: apt-get source nginx), add the
patch to quilt and then build it (preferably using pbuilder if you're building
a binary package locally).

EDIT: Or use the nginx repository from
[http://nginx.org/en/linux_packages.html](http://nginx.org/en/linux_packages.html)

~~~
yeukhon
I have heard from people who work in operating security at tech giants that
they don't build from source or use ppa because to them stable release is
stable and if a release is tag stable for a specific ubuntu release it means
it has met the standard. I am not sure if this is crap or what. When I run my
own in-house apps I use the latest from ppa.

~~~
brokenparser
It's mostly crap. What you get with universe and multiverse packages is
essentially a snapshot of Debian development at the time U+1 was forked from
Debian testing or unstable. There are packages which are also in the stable
branch of Debian or may later _become_ packages in that branch, but often more
changes are made before it goes into the next Debian stable release.

Secondly, a package in Debian stable mustn't have any applicable release
critical bugs _at the time the release is made_. If after release a package
(in Debian, Ubuntu or any other derivative) is discovered to allow for remote
code execution in its default configuration for instance, there's no hiding
behind what it says on the tin. The bug doesn't care how it's labeled and you
should act on it.

Thirdly, packages in universe and multiverse only get community support, as
opposed to support from Canonical for the duration of the support cycle. The
entire point of having a repository system (like apt or yum) is that you can
mix and match them to your liking and choose which packages may come from
which source. So if you can get better support elsewhere, there should be no
stopping you from subscribing to that support channel.

Personal package archives I'd generally not recommend because they may not be
vetted as well as the more official repositories and the support commitment
(when it exists) might not be at the same level. Could be better or worse, but
you'll have to evaluate that on a case-by-case basis.

------
MickaelVanAken
Wow, well I've updated to fixed versions from
[http://nginx.org/en/linux_packages.html](http://nginx.org/en/linux_packages.html)
before even being noticed about vulnerability.

~~~
mattrad
I've just tried to update to stable using the instructions there, and when I
ran apt-get install nginx, it returned:

dpkg: error processing /var/cache/apt/archives/nginx_1.4.4-1~precise_i386.deb
(--unpack): trying to overwrite '/usr/sbin/nginx', which is also in package
nginx-full 1.1.19-1ubuntu0.2 dpkg-deb: error: subprocess paste was killed by
signal (Broken pipe) Errors were encountered while processing:
/var/cache/apt/archives/nginx_1.4.4-1~precise_i386.deb E: Sub-process
/usr/bin/dpkg returned an error code (1)

Any suggestions on how to fix this? Ta.

~~~
oakwhiz
What I did to fix this error was first back up my configuration, then
uninstall packages nginx, nginx-common, and nginx-full. Then I installed nginx
again and there were no problems.

~~~
mattrad
That's done it! Where's the HN tip jar? :)

------
graue
Shoot, no patch for the 1.2.x series? That's disappointing. It's not _that_
old, is it? I feel like I upgraded to 1.2.x, which was then the newest stable
branch, just over a year ago.

~~~
BobVerg
It's _that_ old.

As I know, 1.2.x actually is obsoleted since May 2013, and there is no more
support or bugfixes after this date.

~~~
nashe
Unfortunately, Debian's stable version is 1.2.1.

~~~
mappu
Debian does commit to security support for packages in main, i expect they
will backport the patch to their current version and send notification from
security-announce when an update is released. Also keep an eye on
[https://security-tracker.debian.org/tracker/CVE-2013-4547](https://security-
tracker.debian.org/tracker/CVE-2013-4547)

~~~
Fuxy
Ironically I'm getting an SSL error from them and it forces you to use https.

------
krenoten
Does anyone know what the initial estimated severity of this one is?

------
jacobmarble
Context anyone?

~~~
chrisbolt
[http://nginx.org/en/CHANGES-1.4](http://nginx.org/en/CHANGES-1.4) says

    
    
      Changes with nginx 1.4.4                                         19 Nov 2013
      
        *) Security: a character following an unescaped space in a request line
           was handled incorrectly (CVE-2013-4547); the bug had appeared in
           0.8.41.
           Thanks to Ivan Fratric of the Google Security Team.
    

[http://comments.gmane.org/gmane.comp.web.nginx.english/41133](http://comments.gmane.org/gmane.comp.web.nginx.english/41133)

