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.
Or am I misunderstanding this?