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