Vulnerability disclosure: nginx can follow symlinks to sensitive files owned by the http user #206

New issue

Closed

opened 2023-07-10 20:27:39 +00:00 by a · 2 comments

a commented

2023-07-10 20:27:39 +00:00

Owner

I know this write-up is a bit late, but several people wanted to learn more about this vulnerability, so here it is.

On 2023-06-14, @ersei discovered that because nginx follows symlinks, if you create a website in /srv/http/pages like this:

ln -s /var/log/nginx/access.log /srv/http/pages/exploit/access.log

On the filesystem, the log is only accessible by the http user. But when you visit https://exploit.exozy.me/access.log, nginx, which runs as the http user will follow the symlink and serve the entire contents of the access log. This exploit works for any files owned by the http user, which also include nginx stuff in /proc. This is obviously very bad.

The solution is to add disable_symlinks if_not_owner to the global /etc/nginx/nginx.conf config file which makes nginx stop following symlinks if the owner of the symlink and owner of the target file are different. This means that you would have to create the symlink as the http user, but that would mean the http user is already compromised. I could have also chosen to disable following symlinks completely, but sometimes symlinks are useful. This solution broke Nextcloud, so I had to manually add disable_symlinks off to Nextcloud's nginx config. It also broke https://fortune.exozy.me since that website is a symlink to /etc/motd.d/fortune, so I replaced it with a hard link. Hard links are not vulnerable to this exploit because in order to create a hard link to a file, you have to be the same user as that file.

The moral of the story is that if your web server is serving user content, you must disable arbitrary symlinks. I'm guessing nginx has following symlinks enabled by default since usually people only serve trusted content.

Anyways, thanks @ersei for finding and reporting this!

I know this write-up is a bit late, but several people wanted to learn more about this vulnerability, so here it is. On 2023-06-14, @ersei discovered that because nginx follows symlinks, if you create a website in `/srv/http/pages` like this: ``` ln -s /var/log/nginx/access.log /srv/http/pages/exploit/access.log ``` On the filesystem, the log is only accessible by the `http` user. But when you visit https://exploit.exozy.me/access.log, nginx, which runs as the `http` user will follow the symlink and serve the entire contents of the access log. This exploit works for any files owned by the `http` user, which also include nginx stuff in `/proc`. This is obviously very bad. The solution is to add `disable_symlinks if_not_owner` to the global `/etc/nginx/nginx.conf` config file which makes nginx stop following symlinks if the owner of the symlink and owner of the target file are different. This means that you would have to create the symlink as the `http` user, but that would mean the `http` user is already compromised. I could have also chosen to disable following symlinks completely, but sometimes symlinks are useful. This solution broke Nextcloud, so I had to manually add `disable_symlinks off` to Nextcloud's nginx config. It also broke https://fortune.exozy.me since that website is a symlink to `/etc/motd.d/fortune`, so I replaced it with a hard link. Hard links are not vulnerable to this exploit because in order to create a hard link to a file, you have to be the same user as that file. The moral of the story is that if your web server is serving user content, you must disable arbitrary symlinks. I'm guessing nginx has following symlinks enabled by default since usually people only serve trusted content. Anyways, thanks @ersei for finding and reporting this!

👍 2

a added the

security

label 2023-07-10 20:27:39 +00:00

a closed this issue

2023-07-10 20:27:50 +00:00

nvpie commented

2023-08-18 10:10:40 +00:00

How come it does not have CVE for it?

a commented

2023-08-30 16:21:29 +00:00

Author

Owner

How come it does not have CVE for it?

Probably because this is intended behavior. Both Nextcloud and Mastodon use this feature. And if you only serve trusted content, it's not really a problem at all. I guess the real problem is that there should be greater awareness about needing to disable following symlinks if you do serve untrusted content.

> How come it does not have CVE for it? Probably because this is intended behavior. Both Nextcloud and Mastodon use this feature. And if you only serve trusted content, it's not really a problem at all. I guess the real problem is that there should be greater awareness about needing to disable following symlinks if you do serve untrusted content.