Nginx security advisory (CVE-2013-4547) | Hacker News Reader

Nginx security advisory (CVE-2013-4547)

mailman.nginx.org

134 pointszzzcpan55 comments

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.

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?

Thing is, there might be some other bug somewhere that would allow an attacker to create just such a directory (e.g. getting access to the same dir through samba or by exploiting a cgi script). Now you're vulnerable to a lot more trouble, so don't assume safety just because one particular bug appears to be more or less innocent.

Right, on Linux, for the scenarios described in the advisory, you'd need to have a trailing space in a file/folder name.

But if you just so happen to run nginx on Windows, you can loose the trailing space requirement as any file is accessible with a space at the end. Also in "/foo /../protected/file" scenario, foo doesn't need to exist.

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

No, the vulnerability is about literal space.

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

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

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

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)"

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?

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.

The advisory recommends the Nginx specific no response header (444) rather than the 403 forbidden header.

A better link: http://mailman.nginx.org/pipermail/nginx-announce/2013/00012...

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

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

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

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

http://pragprog.com/the-pragmatic-programmer/extracts/tips

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

Next we'll use mix twice and partially evaluate a compiler generator ;)

You've obviously never heard of yacc and lex then or bison?

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/ (this was top notch)

http://gulliver.eu.org/free_software_for_formal_verification

I want to name: http://www.eschertech.com/products/index.php and 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.

  > Is this a lame bug?

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

What is the goal of the Nginx httpd then?

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

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

Try replacing /etc/nginx/fastcgi_params with the one from 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.

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!

I'll try that when I get home - thanks!

From memory the Debianish distro packages read the configs from different locations than the mainline nginx packages.

What's wrong with PHP? I wasn't aware that any more recent Nginx version broke it.

Nothing wrong with PHP itself, but the stock/newer nginx must read configs differently, and so it's not a simple "remove old nginx, install new nginx" upgrade, as it no longer served up php when I upgraded...

I don't think Nginx has ever changed its config format. Care to share the problem description?

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

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

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

If you can fix the bug in packaging, why not submit the fix and make it available to all Ubuntu users? As you say, nginx is in universe. This means that it is community supported, and anybody can contribute the fix (in the form of a debdiff with the quilted patch, as you describe) and have it sponsored and the package updated.

I would be extremely surprised if Debian did not update it. Ubuntu I'm less sure about, mostly because I'm less familiar with their security update policies.

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.

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.

> No bug exists in ... the Debian bug tracking system

There is one now: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730012

And now fixed in Debian: http://ftp-master.metadata.debian.org/changelogs/main/n/ngin...

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

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.

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.

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

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.

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.

Unfortunately, Debian's stable version is 1.2.1.

Just use third party APT packages.

You can either use the Phusion Passenger one: https://www.phusionpassenger.com/install_debian

Or the Nginx.org one: http://nginx.org/en/linux_packages.html

Both support Debian 6 and 7, and both supply the latest Nginx stable version.

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

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

Last time it took them six months to do so.

There is a patch for older versions: http://nginx.org/download/patch.2013.space.txt And nginx -V will show you how to rebuild it manually.

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

Context anyone?

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

Reply on news.ycombinator.com