At which OS privilege level log4j usually runs?

Question

Considering that a RCE vulnerability has been recently found in the log4j library, a library used in a lot more applications than I thought. The following question comes to my mind.

If an attacker successfully exploits log4shell, does the payload will run as root or as a regular (less-privileges) user?

In other words, does the payload execution privileges level depends of at which privileges level the service or application that uses log4j runs?

In case of the payload running at regular user, the attacker would need a privilege escalation in addition to log4shell in order to gain root privileges. It would be more difficult to control the entire machine and make more damages (such as disabling system auditing tools to hide other malicious activities, install system-wide keyloggers or any kind of spywares for example).

Answer 1

That depends entirely on your system setup!

From a technical point of view, the RCE is executed with the same permissions as the java process on the system. This could mean running as root, but more often than not, it means running as a less-privileged user. When I google "debian tomcat", this is the first guide I come across, and it suggests setting up a dedicated user for the tomcat process.

Judging by my personal experience doing penetration tests, this is how you'd expect a server to be set up. As you correctly assessed, this means an attacker would need to find some way to escalate their privileges. On a properly set up system, that should not be possible, but you never know what sysadmins do when the day is long and hours don't want to pass.

Answer 2

Root privileges are a red herring and fairly irrelevant in a typical modern server setup.

As-is, the log4shell RCE exploit effectively gives the attacker all information the Java server process can access.

With this, the attacker typically gets:

• Read and write access to the application's database.
• various API keys and passwords to other systems.
• probably all active users' credentials (which may be reused elsewhere or outright be identical to more critical systems via a central identity management like (sic!) LDAP).
• and of course they can start processes, like a botnet client, cryptominer or spam engine.

And that's basically already the crown jewels - the server is usually a VM or container with nothing else running on it and nobody ever logging into it directly. Who cares about getting root there? Root privileges are an intermediate step towards business goals, not a goal in and of themselves.

And even if you really care about root privileges: privilege escalation vulnerabilities are pretty common - and often discounted since "it's a server, we don't have untrusted OS users".

Answer 3

I have posted a related question in order to obtain reputable and authoritative answers.

Here is my answer:

1.) CVE-2021-44228 involves injecting a malformed string to a Java application that employs specific versions of the log4j library. If properly constructed, this string can instantiate the library's lookup feature to query a malicious LDAP server, which through a properly formatted response, can execute commands on the vulnerable application's host.

2.) While there may be additional vulnerabilities that could be exploited through said remote code execution on the target host, there is no indication that this exploit intrinsically performs privilege escalation methods.

3.) The execution context of a typical Java based web application likely has some elevated privileges, including write access to application or service configuration files, as well as the ability to launch\stop\start published services. In this case, I agree with the high severity level.

4.) A different scenario involves the instantiation an arbitrary Java stack by a non-privileged user. The typical execution context here would be much more constrained in terms of systemic impact. For example, where a standard user level account only has access to user-land capabilities and is much more limited in terms of write access to system files. Additionally, it would be somewhat atypical for user-instantiated applications to be remotely accessible.

5.) If my assertions are correct, the severity of CVE-2021-44228 is significantly reduced for Java applications running within an unprivileged execution context.

6.) The lack of authoritative clarification from the main stakeholders on the difference between these common use cases in terms of severity is troubling. I would like to get confirmation of my assertions from an authoritative, reputable source.