REDHAT-BUG-1367447: High severity Red Hat Enterprise Linux vulnerability

Q: Which systems have the root-level code execution exposure?

Systems using classic /etc/init.d scripts, including Red Hat Enterprise Linux 6 and earlier, are exposed because the Tomcat init script sources /etc/sysconfig/tomcat and executes its contents with root privileges during service start, stop, or restart.

Q: What access would an attacker need to exploit this on affected init-script systems?

An attacker would need the ability to modify /etc/sysconfig/tomcat through membership or equivalent access to the tomcat group, since the file is owned root:tomcat and group-writable (664). They would then need a Tomcat service start, stop, or restart to cause the modified content to run as root.

Q: Does a compromised web application running as the tomcat user directly gain root access?

No. The provided information states that a malicious or compromised web application already running with tomcat user privileges cannot directly escalate privileges through this issue.

Q: How does the impact differ on Red Hat Enterprise Linux 7?

On Red Hat Enterprise Linux 7 with systemd, /etc/sysconfig/tomcat is not directly executed with root privileges. It is still used to initialize the Tomcat service environment.

Published Aug 16, 2016

Updated

It was discovered that Tomcat packages in certain versions of Red Hat Enterprise Linux use incorrect permissions for /etc/sysconfig/tomcat configuration files. The file is writable to tomcat group (root:tomcat, 664). On systems using classic /etc/init.d init scripts (i.e. on Red Hat Enterprise Linux 6 and earlier), the file is sourced by the Tomcat init script and its content executed with root privileges when Tomcat service is started, stopped or restarted.

On Red Hat Enterprise Linux 7 using systemd, the file is not longer directly executed with root privileges, but it's still used to initialize environment for the Tomcat service. This would not allow a malicious or compromised web application deployed on Tomcat and already running with tomcat user privileges to directly escalate privileges.

Affected Software

2 affected components

Red Hat Enterprise Linux<7

Red Hat Enterprise Linux>=6<7

Event History

Aug 16, 2016

Data Sourced

via Red Hat·12:33 PM

DescriptionSeverityAffected Software

Frequently Asked Questions

Which systems have the root-level code execution exposure?

Systems using classic /etc/init.d scripts, including Red Hat Enterprise Linux 6 and earlier, are exposed because the Tomcat init script sources /etc/sysconfig/tomcat and executes its contents with root privileges during service start, stop, or restart.

What access would an attacker need to exploit this on affected init-script systems?

An attacker would need the ability to modify /etc/sysconfig/tomcat through membership or equivalent access to the tomcat group, since the file is owned root:tomcat and group-writable (664). They would then need a Tomcat service start, stop, or restart to cause the modified content to run as root.

Does a compromised web application running as the tomcat user directly gain root access?

No. The provided information states that a malicious or compromised web application already running with tomcat user privileges cannot directly escalate privileges through this issue.

How does the impact differ on Red Hat Enterprise Linux 7?

On Red Hat Enterprise Linux 7 with systemd, /etc/sysconfig/tomcat is not directly executed with root privileges. It is still used to initialize the Tomcat service environment.

REDHAT-BUG-1367447: High severity Red Hat Enterprise Linux vulnerability

Affected Software

Event History

Frequently Asked Questions

Which systems have the root-level code execution exposure?

What access would an attacker need to exploit this on affected init-script systems?

Does a compromised web application running as the tomcat user directly gain root access?

How does the impact differ on Red Hat Enterprise Linux 7?

Company

Resources

Contact

Frequently Asked Questions

Which systems have the root-level code execution exposure?

What access would an attacker need to exploit this on affected init-script systems?

Does a compromised web application running as the tomcat user directly gain root access?

How does the impact differ on Red Hat Enterprise Linux 7?