No one sane runs confluence as root. But RCE is RCE. It's always serious, even if the user isn't privileged. It's significantly easier to get root access once you have access to an unprivileged acccount than without. And with tools like Confluence, there's a good chance that if you control the application, you can intercept login requests and steal credentials. Which can then likely help you gain access to other services.

It would help if the run-user was not the same user that owns the files on disk. The run-user should only need to write logs and caches and databases. Not jsp files.

I usually try and make this so, but it is often very hard to impossible. Vendors do not make it easy.

>No one sane runs confluence as root.

See "Figure 1. Process tree in Volexity Volcano Server from the infected Confluence server"

https://www.volexity.com/wp-content/uploads/2022/06/Figure1....

I didn't mean running as non-root would fix the problem, just that a remote root RCE was worse than a normal RCE.

> And with tools like Confluence, there's a good chance that if you control the application, you can intercept login requests and steal credentials.

I thought Atlassian products were well trusted. Is that not the case?

They've had a string of script-injection vulnerabilities with similar severity -- the last was less than a year ago:

https://confluence.atlassian.com/doc/confluence-security-adv...

Each time, they patch the particular vulnerable script, but they don't seem to have done anything systematic which would eliminate the entire class of vulnerabilities (like, say, adding taint-checking for unquoted, client-supplied content before running code as an OGNL script). So they keep coming up.

They’re widely used, which is not the same. If you’re a customer you’ll routinely encounter bugs, clumsy or inaccessible UI, annoying limitations, and performance issues which take ages to get fixed if ever. I would not assume that they’re better at security than everything else.

Nailed it.

Let's also admit that setting up iptables is harder than it needs to be. I mean, not after the first twenty times... you eventually remember all the arcane logic and expect everyone else to as well.

If you're manually editing iptables rules in production in current year you're doing it wrong anyway, you should have some form of config management like ansible/salt/puppet etc that make it dead simple to add rules or at the very least just use firewalld or something

In the past, I've found making tomcat listen on unprivileged 8080 and proxying it using nginx on 443 works well.

Even better running the system as a Docker, or other, container image with read only filesystem.

who in the hell does this?

Mostly Linux-illiterate people, who want to bind to privileged ports (443), and have no idea about systemd sockets[1] and socket-activation[2], so they stick with the first solution that works.

Most people don't know that you can have systemd bind to the privileged ports for you, and hand over the fd to the port to your (unprivileged) process.

Same goes for docker/containerd btw, if you run docker as root nowadays, you are doing it wrong.

[1] https://www.freedesktop.org/software/systemd/man/systemd.soc... [2] https://www.freedesktop.org/software/systemd/man/systemd-soc...