Inclusion Of Security Fixes For Externally Reported Security Bugs In The Critical Patch Updates

Hello, my name is Clement Chen. I am a principal security analyst in Oracle's Security Alerts Group. My primary responsibility is to triage externally reported security vulnerabilities and to ensure their timely resolution through Oracle's Critical Patch Update program, which is Oracle's primary means of releasing security fixes for all Oracle products.

In today's blog I will answer a question I am often asked. This question is "what are the criteria used by Oracle to decide whether a vulnerability warrants a fix in the CPU?"

The criteria used by Oracle to decide whether a vulnerability warrants a fix in the CPU are simple. All externally reported exploitable security vulnerabilities are considered for inclusion in the Critical Patch Update.

Obviously, to understand this policy, one must first understand what we consider to be an "exploitable vulnerability". In my group, we define a software flaw as an "exploitable" security vulnerability if it passes the following two tests:
(1) There is at least one attack surface through which the flaw can be exploited.
(2) If exploited, the software flaw has a non zero CVSS impact which allows attacker to:
- see or acquire data he/she should not have access to (confidentiality); and/or
- modify data he/she should not have access to (integrity); and/or
- prevent other users to access shared data or system resources, when he/she should not be able to (availability).

The first test looks at the existence of an attack surface for the vulnerability. In practice, it is not always straightforward to find attack surfaces where a software flaw can be exploited. In some cases, an attack surface only exists in a small time window; in other cases, an attack surface is only present when software is under some specific configurations. Thus, we always spend a significant amount of time trying to get a full and accurate understanding of the reported issue and its implication. We consider the first test failed only in cases where we are sure that no attack surface exists for a software flaw. In certain instances, the flaw is not directly exploitable by itself but can only be exploited when combined with other vulnerabilities. In this case (blended threat), we generally do not consider it as "exploitable". In the rare cases where we cannot decide, we tend to err on the side of being cautious, and will deem the flaw as "exploitable".

The second test looks at the security impact caused by the software flaw if it is successfully exploited. The impact is usually measured using the confidentiality, integrity, and availability metrics. The scope of the impact will also be considered: that is, whether the impact is limited to the realm of the affected software, or whether it can be extended to the whole operating system (as in a full system compromise).

In the context of this second test, Oracle uses the Common Vulnerability Scoring System (CVSS) definitions of "impact". Since Eric Maurice, in an earlier blog entry, discussed CVSS, I will not discuss again the standards in detail, except to state that, while the CVSS Base Score cannot capture all the subtleties of security flaws, it makes it simple, understandable, and easy to compare security vulnerabilities. A CVSS Base Score ranges from 0 to 10.0. Simply put, a CVSS score above zero means that a software flaw will have some security impact if exploited. A CVSS score of zero means that the software flaw has no security impact. Thus, Oracle considers all externally reported vulnerabilities that have a non-zero CVSS base score as candidates for inclusion in a Critical Patch Update.

It has been my experience that the application of these two tests tends to result in classifying many software flaws as "exploitable" security vulnerabilities. In fact, most of the vulnerability reports my group has received are exploitable security vulnerabilities. It is much more difficult to come with examples of security flaws that would be classified as not exploitable security vulnerabilities under these two tests. The following three examples will help you understand what we think is NOT an exploitable security vulnerability:
• Example 1: A SQL injection issue in a private PL/SQL routine is not an exploitable security vulnerability as long as there is no known path to it from public routines. This is because there is no publicly available attack surface (the first criteria).
• Example 2: A SQL injection issue in a PL/SQL routine that is to be run as invoker's right is not an exploitable security vulnerability as long as there is no known path to the invoker's rights routine from a definer's rights routine. This is because invoker's rights means that the PL/SQL routine runs with the privilege of the caller so no privilege escalation is possible. However, if the routine is a definer's rights routine and it could have higher privileges than an attacker, then privilege escalation is possible and CVSS base score will be greater than zero.
• Example 3: A buffer overflow issue that can ONLY cause a crash of the current user session is NOT an exploitable security vulnerability. Here, "only" means that the crash would not put the database in an unstable state and the crash does not produce a huge trace file on the system to fill up the disk space. In this case, while there is an attack surface, there is no real security impact - one can simply type "quit" to have the same impact.

I'd like to point out that, while non-exploitable security flaws do not necessarily warrant a fix in a CPU; it does not mean that we won't take any action! For example, the SQL injection issues I mentioned above will still be fixed because we understand that, as a good security practice, all inputs needs to be sanitized before their use. We will however deliver the appropriate fix as part of a patch set or in a future release of the product, rather than through the CPU program.

Oracle has also put in place a means to recognize those external researchers who discover issues that may not always be classified as exploitable vulnerabilities. Starting with the July 2008 CPU, Oracle has instituted a Security-In-Depth recognition program to provide credit to people who provide information, observations or suggestions to Oracle pertaining to security issues that result in significant modifications of Oracle code or documentation in future releases, but are not of such a critical nature that they are distributed in Critical Patch Updates.

For More Information:

The Critical Patch Updates and Security Alerts page is located at

Oracle Software Security Assurance web site is located at


Post a Comment:
Comments are closed for this entry.

This blog provides insight about key aspects of Oracle Software Security Assurance programs.


« July 2016