Rating and CVSS v2
It's important to know how severe a security flaw is, so you can plan your response accordingly. Does the latest flaw have a high impact and need to be patched today, or can it wait until your planned upgrade next month? To communicate the risk of each JBoss security flaw, Red Hat uses a four-point severity scale of low, moderate, important and critical, in addition to Common Vulnerability Scoring System (CVSS) version 2 base scores. Most of the time the CVSS v2 base scores are closely correlated to the four-point severity scale.
CVSS v2 base scores give a detailed severity rating by scoring the constant aspects of a security flaw. The constant aspects include the Access Vector (AV), Access Complexity (AC), Authentication (Au), Confidentiality impact (C), Integrity impact (I), and Availability impact (A). We use CVSS version 2, the current version as of writing. This is covered in greater detail on the Issue Severity Classification page. If you are unfamiliar with CVSS, reviewing the A Complete Guide to the Common Vulnerability Scoring System Version 2.0 document may help in understanding the rest of this article.
JBoss security flaws
The core of all of Red Hat's JBoss products is the JBoss Application Server (JBoss AS). JBoss AS runs atop the Java Virtual Machine (JVM) in a single process, acting as a container for all the applications deployed on it. The process is run by an unprivileged jboss system user, not as the administrator. This is important to consider when rating JBoss security flaws as the impact of exploiting a JBoss flaw is limited to:
- All code deployed on the JBoss server
- The context of the system user running the JBoss server process
The impact component of a CVSS v2 score is based on a combined assessment of three potential impacts: Confidentiality (C), Integrity (I) and Availability (A). Each of these can be rated as None (N), Partial (P) or Complete (C). For example, the following CVSS v2 impact score:
Means that exploiting the flaw would have no impact on system confidentiality, partial impact on system integrity and complete impact on system availability (that is, the system would become completely unavailable for any use, for example, via a kernel crash). Because the JBoss server process runs as an unprivileged user and is isolated from the host operating system, JBoss security flaws are only rated as having impacts of either None (N) or Partial (P). For example, a remote code execution flaw on JBoss may allow you to run arbitrary code within the JBoss server process. However, it will not allow you to run arbitrary code on the host operating system unless combined with a different privilege escalation flaw in the JVM or host operating system. Therefore, such a flaw would be rated as having only a partial impact on integrity (I:P).
This is the highest possible severity and CVSS score for a JBoss flaw that does not affect native components, with all impacts rated as partial (C:P/I:P/A:P). This was the flaw exploited by the JBoss worm.
This flaw also has all impacts rated as partial (C:P/I:P/A:P), but the severity is lower since the Access Complexity is Medium (AC:M). This is because only users who deployed particular kinds of applications based on the seam framework that use Expression Language (EL) in a certain way were vulnerable to this flaw; a default installation of JBoss products was not exploitable.
This flaw allows an attacker to read confidential information accessible to the user running the JBoss server process (C:P), but not execute code or affect the availability of the server.
This flaw describes a mechanism for malicious applications to bypass security manager restrictions. A malicious application could expoit this flaw to expose server files that should be restricted by the security manager (C:P) or to trigger a crash of the server process (A:P). Although this flaw impacts both confidentiality and availability, it can only be exploited by a malicious, deployed application, with the security manager enabled. Furthermore, flaws only exploitable by local attackers (in this case, malicious applications) rather than remote attackers are a considerably reduced threat. Therefore, the severity rating for this flaw is low.
JBoss security flaws often differ greatly in their impact, with some low impact flaws only affecting specific use cases, and critical flaws requiring urgent attention to avoid the spread of malware and worms. Understanding how we rate JBoss security flaws enables JBoss users to determine their impact to the users' systems and manage their response accordingly. Consuming and deploying JBoss security patches is an important topic, one that we will mention in an upcoming post around how we ship JBoss security patches.