But do you know, if they’re a nicer options finder? The one I found where you just search all several thousand options kinda sucks. I want to just see my package (say, ssh) and just the ssh options, but the results get littered with irrelevancy.
When I roughly know what I'm doing I use search.nixos.org; if you give it the full services.foo prefix it's usually relevant enough, e.g. for ssh you'd want "services.openssh", which you can find skimming through the results of just searching 'ssh' first:
For anything I'm not 100% sure will be obvious I search through a local clone of the nixpkgs repo directly, but I'll be honest and say I just never took time to search for a better tool
My main usage of Nix is on non-NixOS machines, and I use Home Manager, and while it has a similar problem, just searching the options in the packages it provides configuration for is a smaller issue.
Not sure if this helps you at all or not, it really depends on your usage of Nix, but for managing user configuration I do recommend Home Manager.
At risk of asking a dumb question, is there any good reason that you’d want nginx to allow traversing into “..” from a URL path? It just seems like problems waiting to happen.
Edit: Actually, I’m a bit lost as to what’s happening in the original vuln. http://localhost/foo../secretfile.txt gets interpreted as /var/www/foo/../secretfile.txt or whatever… but why wouldn’t a server without the vulnerability interpret http://localhost/foo/../secretfile.txt the same way? Why does “..” in paths only work sometimes?
I've only implemented a handful of HTTP servers for fun, but I've always resolved relative paths and constrained them. So I'd turn "/path/images/../flag.txt" into "/path/flag.txt", which would not start with the root "/path/images/" and hence denied without further checks.
The problem is that a URL isn't actually a path. It's an abstract address to a resource which can be a directory or file (or an executable or stream or ...).
In this case part of the URL is being interpreted by nginx as a directory (http://localhost/foo) due to how that URL is mapped in the configuration to the local filesystem. Apparently it references a directory, so when nginx constructs the full path to the requested resource, it ends up with "${mapped_path}/../secretfile.txt" which would be valid on the local filesystem even if it doesn't make sense in the URL. Notice how the location of the slashes doesn't matter because URLs don't actually have path elements (even if we pretend they do), they are just strings.
This is a very common problem that I have noticed with web servers in general since the web took off. Mapping URLs directly to file paths was popular because it started with simple file servers with indexes. That rapidly turned into a mixed environment where URLs became application identifiers instead of paths since apps can be targeted by part of the path and the rest is considered parameters or arguments.
And no, it generally doesn't usually make sense to honor '.' or '..' in URLs for filesystem objects and my apps sanitize the requested path to ensure a correct mapping. It's also good to be aware that browsers do treat URLs as path-like when building relative links so you have to be careful with how and when you use trailing '/'s because it can target different resources which have different semantics on the server side.
Just guessing, but NginX probably either checks for "/foo/bar/.." and disallows it, or normalizes it to "/foo/" but "/foo/bar.." is a perfectly valid file name, so it doesn't get caught by the net checking for this.
That fully depends upon the file permissions. In this case, let's assume that a user has permissions to read files all the way from the web index directory (../index.html) back to the root directory (/). At that point, since they have permission to traverse down to the root directory, they now have permission to view any world viewable file that can be traversed to from the root directory, for instance /etc/passwd.
In other words, imagine a fork with three prongs, and your web server resides on the far right prong. Imagine that the part of the fork where the prongs meet (the "palm" of the fork) is the file system. If your web server residing on the far right prong of that fork allows file permission to files and directories that lead all the way to the palm of the fork, at that point you could continue accessing files on other prongs once you have reached the palm.
Isn't setting correct permissions for www-data like, the first note in a bunch of "secure your web server" tutorials? I thought if read is only set for the directory with actual public files, and not for the parent directory, there should be no traversal possible like this?
How is this not seen as a vulnerability in nginx? This behavior is utterly absurd, seems to have no beneficial purpose, and straightforwardly exploitable.
It's done for speed. Straightforward text replacement is so much faster than checking to see if a path is properly terminated by a slash. And remember that Nginx became popular due to benchmarks that showed that it was more "web scale" than Apache2.
I find it hard to believe that searching for “..” would even show up in a benchmark.
In any case, it seems that nginx does try to search for .. but has a bug in the corner case where the “location” doesn’t end with a slash. I assume there’s some kind of URL normalization pass that happens before the routing pass, and if the route matches part of a path component, nothing catches the ..
If I’m right, this is just an IMO rather embarrassing bug and should he fixed.
Your comment makes nginx sound like some fly-by-night server that only achieved its performance by making lots of tiny-yet-dangerous "optimisations" like this one.
More likely it is an omission, which could be rectified with a warning or failure running nginx -t (verify configuration).
The actual performance comes from an architectural choice between event vs process based servers, as detailed in the C10k problem article. [1]
They could simply normalize the paths when parsing the configuration file. The overhead wouldn’t show up in benchmark because it only happens once at startup (and maybe when the conf file changes)
OK hear me out: a Linux capability like option that removes the .. option from the kernels file name parser.
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.
That would break so many things that it would be insane to do.
You could just run nginx as a separate user with very limited rights, or just run it on Docker. This, plus updating regularly usually fixes 90% of security issues.
Most (I hope all) distributions already run nginx as a separate user. It's best practice.
But that won't help if you alias to "/foo/bar/www" and the the application has a SQLite database at "/foo/bar/db.db", which the nginx user has to have access to. Same if you run it in a container (or lock down permissions using systemd).
I don't agree. Those kinds of paths are often result of concatenation of several configuration options. Like APP_DIR=/some/app/bin; LOG_DIR="$APP_DIR/../logs". And APP_DIR comes to you from distro scripts, so you're not going to fork those scripts and support your own fork across updates, you just build upon those scripts.
It's something else in the kernel, there we have the permission system which we rely on.
If you are serving files to web from the folder, the web framework should handle not taversing the public root folder it was tasked to serve. If are rolling your own, well now you have to consider all kinds of stuff, including this.
I don't think this would have prevented it. Removing ".." segments from paths is part of URL parsing and required by the HTTP specification. Nginx very likely does this too.
> 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.
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.
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.
Cross-platform, written in Rust, straightforward configuration, secure defaults, also has a hardened container image and a hardened NixOS module.
I wouldn't recommend Caddy. Their official docker image runs as root by default [1], and they don't provide a properly sandboxed systemd unit file [2].
[Unit]
Description=Caddy webserver
Documentation=https://caddyserver.com/docs/
After=network-online.target
Wants=network-online.target systemd-networkd-wait-online.service
StartLimitIntervalSec=14400
StartLimitBurst=10
[Service]
User=caddy
Group=caddy
# environment: store secrets here such as API tokens
EnvironmentFile=-/var/lib/caddy/envfile
# data directory: uses $XDG_DATA_HOME/caddy
# TLS certificates and other assets are stored here
Environment=XDG_DATA_HOME=/var/lib
# config directory: uses $XDG_CONFIG_HOME/caddy
Environment=XDG_CONFIG_HOME=/etc
ExecStart=/usr/bin/caddy run --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
# Do not allow the process to be restarted in a tight loop.
Restart=on-abnormal
# Use graceful shutdown with a reasonable timeout
KillMode=mixed
KillSignal=SIGQUIT
TimeoutStopSec=5s
# Sufficient resource limits
LimitNOFILE=1048576
LimitNPROC=512
# Grants binding to port 443...
AmbientCapabilities=CAP_NET_BIND_SERVICE
# ...and limits potentially inherited capabilities to this
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
# Hardening options
LockPersonality=true
NoNewPrivileges=true
PrivateTmp=true
PrivateDevices=true
ProtectControlGroups=true
ProtectHome=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectSystem=strict
ReadWritePaths=/var/lib/caddy
ReadWritePaths=/etc/caddy/autosave.json
ReadOnlyPaths=/etc/caddy
ReadOnlyPaths=/var/lib/caddy/envfile
[Install]
WantedBy=multi-user.target
I have used Caddy for years, automatic SSL certificates, does file serving, does reverse proxy, very easy and clear to configure. Single-binary (Go) so easy to "install", single configfile.
Treat any web request like you would a real user on a Linux system you'd need to give access to to download files via scp. Chroot, strict permissions, etc. Can't escape what you can't escape. A ../ should return the same as expected in the shell, permission denied
how is a static site served from S3 considered in these parts of the interweb? i've never done this, but see it as an option, yet i never really hear others using it either.
In my view, it's perfect (okay, maybe slightly less than perfect, and dedicated platforms taking ot to the next level like Netlify, CloudFlare Pages, Firebase Hosting, etc are for their added related services and tools, as well as their generous free tiers). It's pay as you go, scales from zero to infinite, and has zero attack surface or maintenance.
I've run a couple of websites (WordPress or Hugo based, including my personal blog) like that and it's great.
Readit News
(and nixos automatically runs gixy on a configuration generated through it, so the system refuses to build <3)
nginx was once amazing, but it’s decidedly bad now when compared to modern webservers.
But do you know, if they’re a nicer options finder? The one I found where you just search all several thousand options kinda sucks. I want to just see my package (say, ssh) and just the ssh options, but the results get littered with irrelevancy.
https://search.nixos.org/options?channel=unstable&from=0&siz...
For anything I'm not 100% sure will be obvious I search through a local clone of the nixpkgs repo directly, but I'll be honest and say I just never took time to search for a better tool
https://mynixos.com/
> I want to just see my package (say, ssh) and just the ssh options
https://mynixos.com/nixpkgs/options/programs.ssh
Not sure if this helps you at all or not, it really depends on your usage of Nix, but for managing user configuration I do recommend Home Manager.
Edit: Actually, I’m a bit lost as to what’s happening in the original vuln. http://localhost/foo../secretfile.txt gets interpreted as /var/www/foo/../secretfile.txt or whatever… but why wouldn’t a server without the vulnerability interpret http://localhost/foo/../secretfile.txt the same way? Why does “..” in paths only work sometimes?
https://book.hacktricks.xyz/network-services-pentesting/pent...
Am I wrong, or, why doesn't nginx do this?
Deleted Comment
In this case part of the URL is being interpreted by nginx as a directory (http://localhost/foo) due to how that URL is mapped in the configuration to the local filesystem. Apparently it references a directory, so when nginx constructs the full path to the requested resource, it ends up with "${mapped_path}/../secretfile.txt" which would be valid on the local filesystem even if it doesn't make sense in the URL. Notice how the location of the slashes doesn't matter because URLs don't actually have path elements (even if we pretend they do), they are just strings.
This is a very common problem that I have noticed with web servers in general since the web took off. Mapping URLs directly to file paths was popular because it started with simple file servers with indexes. That rapidly turned into a mixed environment where URLs became application identifiers instead of paths since apps can be targeted by part of the path and the rest is considered parameters or arguments.
And no, it generally doesn't usually make sense to honor '.' or '..' in URLs for filesystem objects and my apps sanitize the requested path to ensure a correct mapping. It's also good to be aware that browsers do treat URLs as path-like when building relative links so you have to be careful with how and when you use trailing '/'s because it can target different resources which have different semantics on the server side.
That fully depends upon the file permissions. In this case, let's assume that a user has permissions to read files all the way from the web index directory (../index.html) back to the root directory (/). At that point, since they have permission to traverse down to the root directory, they now have permission to view any world viewable file that can be traversed to from the root directory, for instance /etc/passwd.
In other words, imagine a fork with three prongs, and your web server resides on the far right prong. Imagine that the part of the fork where the prongs meet (the "palm" of the fork) is the file system. If your web server residing on the far right prong of that fork allows file permission to files and directories that lead all the way to the palm of the fork, at that point you could continue accessing files on other prongs once you have reached the palm.
In any case, it seems that nginx does try to search for .. but has a bug in the corner case where the “location” doesn’t end with a slash. I assume there’s some kind of URL normalization pass that happens before the routing pass, and if the route matches part of a path component, nothing catches the ..
If I’m right, this is just an IMO rather embarrassing bug and should he fixed.
More likely it is an omission, which could be rectified with a warning or failure running nginx -t (verify configuration).
The actual performance comes from an architectural choice between event vs process based servers, as detailed in the C10k problem article. [1]
[1] http://www.kegel.com/c10k.html
More like because it was much faster out of the box, and came with many batteries included while Apache2 required mods to be separately install.
Dead Comment
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.
(FreeBSD has this in ordinary openat(2) as O_RESOLVE_BENEATH.)
You could just run nginx as a separate user with very limited rights, or just run it on Docker. This, plus updating regularly usually fixes 90% of security issues.
But that won't help if you alias to "/foo/bar/www" and the the application has a SQLite database at "/foo/bar/db.db", which the nginx user has to have access to. Same if you run it in a container (or lock down permissions using systemd).
../some/path makes sense sometimes at least
... but I'd imagine it wouldn't as useful as you think it is, because many apps resolve .. before passing it to the OS
If you are serving files to web from the folder, the web framework should handle not taversing the public root folder it was tasked to serve. If are rolling your own, well now you have to consider all kinds of stuff, including this.
Exposing email and private keys of GCP accounts only gives you $500 reward? WTF. Google being Google I guess.
Hunting for Nginx Alias Traversals in the wild
and the hn submission highlights the bitwarden vulnerability while there is a google one discussed as well.
Cross-platform, written in Rust, straightforward configuration, secure defaults, also has a hardened container image and a hardened NixOS module.
I wouldn't recommend Caddy. Their official docker image runs as root by default [1], and they don't provide a properly sandboxed systemd unit file [2].
[1]: https://github.com/caddyserver/caddy-docker/issues/104
[2]: https://github.com/caddyserver/dist/blob/master/init/caddy.s...
EDITED: phrasing
https://github.com/troglobit/merecat/
Treat any web request like you would a real user on a Linux system you'd need to give access to to download files via scp. Chroot, strict permissions, etc. Can't escape what you can't escape. A ../ should return the same as expected in the shell, permission denied
I've run a couple of websites (WordPress or Hugo based, including my personal blog) like that and it's great.
I personally prefer something like Github Pages, though - it doesn't get much more hands-off than that!