If I understand correctly, this is a vulnerability in self-hosted Bitwarden only. Is that correct?
Hunting for Nginx alias traversals in the wild
81–90 of 165 posts
Re: Hunting for Nginx alias traversals in the wild
#82Please excuse the silly question: Would proper directory and file ownerships not prevent this traversal? If nginx does not run as root, how can it read other files than the ones explicitly assigned to the nginx user?
You are correct. Unfortunately, nginx (and other web servers) generally need to run as root in normal web applications because they are listening on port 80 or 443. Ports below 1024 can be opened only by root. A more detailed explanation can be found here: https://unix.stackexchange.com/questions/134301/why-does-ngi...
Re: Hunting for Nginx alias traversals in the wild
#83Please excuse the silly question: Would proper directory and file ownerships not prevent this traversal? If nginx does not run as root, how can it read other files than the ones explicitly assigned to the nginx user?
You are correct. Unfortunately, nginx (and other web servers) generally need to run as root in normal web applications because they are listening on port 80 or 443. Ports below 1024 can be opened only by root. A more detailed explanation can be found here: https://unix.stackexchange.com/questions/134301/why-does-ngi...
Re: Hunting for Nginx alias traversals in the wild
#84Please excuse the silly question: Would proper directory and file ownerships not prevent this traversal? If nginx does not run as root, how can it read other files than the ones explicitly assigned to the nginx user?
Re: Hunting for Nginx alias traversals in the wild
#85Earlier quoted context omitted.
You are correct. Unfortunately, nginx (and other web servers) generally need to run as root in normal web applications because they are listening on port 80 or 443. Ports below 1024 can be opened only by root. A more detailed explanation can be found here: https://unix.stackexchange.com/questions/134301/why-does-ngi...
Nginx is started as root but it does not run as root, it changes its user after opening log files and sockets. (unless you use a lazy docker container and just run everything as root inside it).
/bin/sh -c set -x && groupadd --system --gid 101 nginx && useradd --system --gid nginx --no-create-home --home /nonexistent --comment "nginx user" --shell /bin/false --uid 101 nginx .....
[1] https://hub.docker.com/layers/library/nginx/latest/images/sh...
Re: Hunting for Nginx alias traversals in the wild
#86Note that this leaks the vault with secrets encrypted - a leak of the cyphertext. > 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. That's a ridiculously low payout.
not compared to the $500 Google gave them
Re: Hunting for Nginx alias traversals in the wild
#87Hunting for Nginx Alias Traversals in the wild
and the hn submission highlights the bitwarden vulnerability while there is a google one discussed as well.
Re: Hunting for Nginx alias traversals in the wild
#88Re: Hunting for Nginx alias traversals in the wild
#89Earlier quoted context omitted.
a password vault contains a lot of long-lived secrets protected by a human-provided key, so it's really not something you want out there, even encrypted.
I would assume most people that are doing self-hosted are securing it behind a VPN like Wireguard instead of opening it to the whole web. (at least I hope so)
I’m aware that this is security through obscurity. The instance’s accounts use strong passwords and MFA.
Re: Hunting for Nginx alias traversals in the wild
#90Please excuse the silly question: Would proper directory and file ownerships not prevent this traversal? If nginx does not run as root, how can it read other files than the ones explicitly assigned to the nginx user?
You are correct. Unfortunately, nginx (and other web servers) generally need to run as root in normal web applications because they are listening on port 80 or 443. Ports below 1024 can be opened only by root. A more detailed explanation can be found here: https://unix.stackexchange.com/questions/134301/why-does-ngi...
Or processes running with the CAP_NET_BIND_SERVICE capability! [1]
Capabilities are a Linux kernel feature. Granting CAP_NET_BIND_SERVICE to nginx means you do not need to start it with full root privileges. This capability gives it the ability to open ports below 1024
Using systemd, you can use this feature like this:
[Service]
ExecStart=/usr/bin/nginx -c /etc/my_nginx.conf
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
User=nginx
Group=nginx
(You probably also want to enable a ton of other sandboxing options, see `systemd-analyze security` for tips)[1]: https://man7.org/linux/man-pages/man7/capabilities.7.html