Log4j Privilege Level

TL;DR

Log4j typically runs at the privilege level of the application it’s embedded in. This is usually a standard user account, but can be higher depending on how the application is configured and deployed. It rarely runs as root or administrator directly.

Understanding Log4j Privilege

Log4j isn’t a standalone service that runs with its own dedicated permissions. Instead, it’s a Java library included *within* other applications (like web servers, databases, and custom software). Therefore, the security context of Log4j is determined by the application using it.

Steps to Determine Log4j’s Effective Privilege

1. Identify the Host Application: First, you need to know which application is using the vulnerable version of Log4j. This could be Apache Tomcat, Spring applications, or others.
2. Check Application Configuration: Examine the configuration files for the host application. Look for how it’s started and what user account it runs under.
   • Linux/Unix: Check systemd unit files (/etc/systemd/system/*.service), init scripts (/etc/init.d/*), or process listings using commands like ps aux | grep <application_name> to find the user running the application.
   • Windows: Use Task Manager (Details tab) or Services app (Properties of the service) to identify the account under which the application is running.
3. Process User on Linux/Unix: Use the following command to see the user Log4j is running as:

   ps -ef | grep <application_name> | grep log4j

   The first column of the output will show the user account.

4. Process User on Windows: Open Task Manager, go to the ‘Details’ tab. Find the process associated with your application (e.g., java.exe if it’s a Java-based app). The ‘User name’ column shows the account running the process.
5. Consider Application Capabilities: If the host application has elevated privileges (e.g., can write to system files or modify network settings), Log4j will inherit those capabilities. However, this doesn’t mean Log4j itself is *directly* configured with those permissions; it’s running through the application.
6. Review Security Logs: Check your operating system’s security logs for any events related to the host application that might indicate privilege escalation or unusual activity.

Common Scenarios

• Web Servers (Tomcat, Jetty): Log4j often runs as a standard user account created specifically for the web server process (e.g., ‘tomcat’, ‘jetty’). It rarely runs as root/administrator.
• Spring Boot Applications: The privilege level depends on how the Spring Boot application is deployed and configured. It’s typically a non-privileged user.
• Custom Java Applications: The privilege level will be determined by the user account used to launch the Java process.

Important Note

While Log4j itself doesn’t usually run with high privileges, a vulnerability in Log4j *can* allow an attacker to execute arbitrary code within the context of the application. This means if the application runs as root/administrator, the attacker could gain those elevated privileges.