FWIW gixy (nginx configuration checker) catches this:
<a href="https://github.com/yandex/gixy/blob/master/docs/en/plugins/aliastraversal.md">https://github.com/yandex/gixy/blob/master/docs/en/plugins/a...</a><p>(and nixos automatically runs gixy on a configuration generated through it, so the system refuses to build <3)
At risk of asking a dumb question, is there any good reason that you’d <i>want</i> nginx to allow traversing into “..” from a URL path? It just seems like problems waiting to happen.<p>Edit: Actually, I’m a bit lost as to what’s happening in the original vuln. <a href="http://localhost/foo../secretfile.txt" rel="nofollow noreferrer">http://localhost/foo../secretfile.txt</a> gets interpreted as /var/www/foo/../secretfile.txt or whatever… but why wouldn’t a server without the vulnerability interpret <a href="http://localhost/foo/../secretfile.txt" rel="nofollow noreferrer">http://localhost/foo/../secretfile.txt</a> the same way? Why does “..” in paths only work <i>sometimes</i>?
How is this not seen as a vulnerability in nginx? This behavior is utterly absurd, seems to have no beneficial purpose, and straightforwardly exploitable.
OK hear me out: a Linux capability like option that removes the .. option from the kernels file name parser.<p>Like web apps have been seen various bypasses involving somehow smuggling two dots somewhere since we were on dial up modems. It's time to look for a way to close this once and for all, as the Linux kernel has done with several other classes of user land bugs.
> The Google VRP Team recognized our work by awarding us a $500 reward for uncovering this vulnerability. They believed the impact on the application wasn't severe enough to warrant a larger reward.<p>Exposing email and private keys of GCP accounts only gives you $500 reward? WTF. Google being Google I guess.
Glad that the leaks are still encrypted. Even companies that specialize in this sort of stuff are not immune to leaks, so this is honestly the best case scenario.
The title is significantly editorialized. The post title is:<p>Hunting for Nginx Alias Traversals in the wild<p>and the hn submission highlights the bitwarden vulnerability while there is a google one discussed as well.
If all you need is a simple way to serve static files that minimizes resource consumption and is reliably secure, what is the state of the art these days? In the past I would probably reach for Nginx, but I wonder if a more focused/less configurable tool would be preferable from a security standpoint.
This is probably a dumb question but why would Bitwarden allow unauthenticated requests to /attachments at all? Even with the Nginx bug, wouldn’t the request have failed if that URL required authentication?
Please excuse the silly question: Would proper directory and file ownerships not prevent this traversal?<p>If nginx does not run as root, how can it read other files than the ones explicitly assigned to the nginx user?
OT but this isn't the first time I've seen someone mistake the verb "delve" with "dwelve":<p>> ...we started dwelving into the code base...<p>The author may not be a native speaker, but this is far from a judgement on their English. I'm just curious about the provenance of this mistake, given the scarcity of words that begin with "dw". At first I thought it was a typo -- especially on a QWERTY keyboard -- but I've seen it often enough to question this.
This has nothing to do with bitwarden. This is a generic directory traversal attack (enabled by Nginx's configuration language being full of serious gotchas).
The article didn't mention permissions, would this still work if the nginx user is denied permissions on things like `/var/log`? I <i>suspect</i> it wouldn't but isn't the most common cause of security flaws going to be unchecked assumptions?<p>As an aside, I didn't know Github code search accepted regex.
> Nginx, a versatile web server pivotal to numerous internet infrastructures, has held a dominant market share since its inception in 2004<p>Horse pucky. In those days, Apache httpd held dominant market share. Nice historical hijacking.
Note that this leaks the vault with secrets encrypted - a leak of the cyphertext.<p>> <i>This vulnerability has been disclosed to Bitwarden and has since then been fixed. Bitwarden issued a US$6000 bounty, which is the highest bounty they issued on their HackerOne program.</i><p>That's a ridiculously low payout.
What would I need to grep my nginx logs for to see if my possibly misconfigured servers were exploited? [^/]+\.\. (not adding a question mark after that regex even though I'm asking if that one would be ok)
Okay so I self-host Vaultwarden, what do I need to do to fix the vulnerability? The article mentions another flavor of the self hosted docker image though.