
W3 Total Cache Nginx – Root Escalation - intheclouddan
https://blog.tarq.io/root-your-box-with-w3tc-and-nginx/
======
sschueller
Why would you ever include user owned configs in nginx?

~~~
TarqDirtyToMe
Trust me, I was just surprised as you are when I saw tutorials suggesting
this.

~~~
mschuster91
Because nginx AFAIK does not have something like Apache's .htaccess.

Yes, htaccess is ugly but at least a server operator can restrict the users
from pwning the machine and only allow rewrite-configs.

~~~
Karunamon
That is exactly the reason. and is the main difference between Apache mode and
Nginx mode in W3TC. The plugin needs to be able to create URL rewriting rules
on the fly, and nginx gives them no sane way to do it.

Htaccess sucks for various reasons, but most of the suck can be worked around.

~~~
zzzcpan
What exactly does it do on the fly? Unless the plugin is running under the
same user as nginx's master process, which is usually root, it won't be able
to send SIGHUP to the master process and reload nginx.conf. So, nothing can be
on the fly here, it's probably just one of those fancy ways to make plugin
installation "easier" and create configs on behalf of the user.

Also, there is no reason to start nginx under root on linux, just give the
binary required net bind capability and start under normal user.

~~~
PuffinBlue
Usually in many simple hosting setups (where W3TC is common) the reloading of
nginx is left to a cron job at some set interval.

Other plugins like iThemes Security will populate the nginx.conf with banned
IP and the such, so it can update on a fairly regular basis.

------
discordianfish
This is a very interesting attack vector. There are many situations where less
privileged users can inject stuff into an nginx config.

~~~
TarqDirtyToMe
I'd be interested to see if any web-based control panels are vulnerable in a
similar way. All of the client_*_temp_path directives are valid in
http,server, and location contexts so you have a lot of flexibility there.

------
nodesocket
What other NGINX directive paths besides "client_body_temp_path" actually
change the owner on-startup?

Seems like NGINX logic should be, if the path exists, it must have correct
permissions already. If not, just fail to start.

~~~
TarqDirtyToMe
All of the client_*_temp_path behave this way so you can actually change
multiple files with one payload.

I am sure there are other ones but I have not had a chance to investigate
further. Another commented mentioned this particular problem is in
ngx_create_paths so that would be a good place to start looking.

The key is to find paths that happen in the master process, not the workers.

------
dchest
Huh, why does nginx even change permissions?

~~~
TarqDirtyToMe
In theory, to make the temp/cache directories more secure I imagine

~~~
dchest
This would make sense if it created those directories, but IMHO it should fail
to start if the path exists and isn't owned by www process. The function that
does chown() is even called ngx_create_paths().

~~~
discordianfish
I agreed, would at least consider it a bug if not a security issue.

~~~
TarqDirtyToMe
Definitely bad behavior. Ideally, no one but privileged users should be able
to edit the configuration imho but this opens the door for attackers.

------
deckiedan
Ouch.

Does SElinux mitigate this? App armour? Dockerised WP and NGiNX?

~~~
ibotty
SELinux does, I don't know about App armour. Dockerized NGiNX will give you
root in the container, which will give you root on the host easily. If you run
NGiNX as non-root-container, you are better off: You can't escalate. You run
as non-root before, and stay non-root.

