Thursday Oct 20, 2016

Common Criteria and the Future of Security Evaluations

For years, I (and many others) have recommended that customers demand more of their information technology suppliers in terms of security assurance – that is, proof that security is “built in” and not “bolted on,” that security is “part of” the product or service developed and can be assessed in a meaningful way. While many customers are focused on one kind of assurance – the degree to which a product is free from security vulnerabilities – it is extremely important to know the degree to which a product was designed to meet specific security threats (and how well it does that). These are two distinct approaches to security that are quite complementary and a point that should increasingly be of value for all customers. The good news is that many IT customers – whether of on-premises products or cloud services - are asking for more “proof of assurance,” and many vendors are paying more attention. Great! At the same time, sadly, a core international standard for assurance: the Common Criteria (CC) (ISO 15408), is at risk.

The Common Criteria allows you to evaluate your IT products via an independent lab (certified by the national “scheme” in which the lab is domiciled). Seven levels of assurance are defined – generally, the higher the evaluation assurance level (EAL), the more “proof” you have to provide that your product 1) addresses specific (named) security threats 2) via specific (named) technical remedies to those threats. Over the past few years, CC experts have packaged technology-specific security threats, objectives, functions and assurance requirements into “Protection Profiles” that have a pre-defined assurance level. The best part of the CC is the CC Recognition Arrangement (CCRA), the benefit of which is that a CC security evaluation done in one country (subject to some limits) is recognized in multiple other countries (27, at present). The benefit to customers is that they can have a baseline level of confidence in a product they buy because an independent entity has looked at/validated a set of security claims about that product.

Unfortunately, the CC in danger of losing this key benefit of mutual recognition. The main tension is between countries that want fast, cookie cutter, “one assurance size fits all” evaluations, and those that want (for at least some classes of products) higher levels of assurance. These tensions threaten to shatter the CCRA, with the risk of an “every country for itself,” “every market sector for itself” or worse, “every customer for itself” attempt to impose inconsistent assurance requirements on vendors that sell products and services in the global marketplace. Customers will not be well-served if there is no standardized and widely-recognized starting point for a conversation about product assurance.

The uncertainty about the future of the CC creates opportunity for new, potentially expensive and unproven assurance validation approaches. Every Tom, Dick, and Harriet is jumping on the assurance bandwagon, whether it is developing a new assurance methodology (that the promoters hope will be adopted as a standard, although it’s hardly a standard if one company “owns” the methodology), or lobbying for the use of one proprietary scanning tool or another (noting that none of the tools that analyze code are themselves certified for accuracy and cost-efficiency, nor are the operators of these tools). Nature abhors a vacuum: if the CCRA fractures, there are multiple entities ready to promote their assurance solutions – which may or may not work. (Note: I freely admit that a current weakness of the CC is that, while vulnerability analysis is part of a CC evaluation, it’s not all that one would want. A needed improvement would be a mechanism that ensures that vendors use a combination of tools to more comprehensively attempt to find security vulnerabilities that can weaken security mechanisms and have a risk-based program for triaging and fixing them. Validating that vendors are doing their own tire-kicking – and fixing holes in the tires before the cars leave the factory – would be a positive change.)

Why does this threat of CC balkanization matter? First of all, testing the exact same product or service 27 times won’t in all likelihood lead to a 27-fold security improvement, especially when the cost of the testing is born by the same entity over and over (the vendor). Worse, since the resources (time, money, and people) that would be used to improve actual security are assigned to jumping through the same hoop 27 times, we may paradoxically end up with worse security. We may also end up with worse security to the extent that there will be less incentive for the labs that do CC evaluations to pursue excellence and cost efficiency in testing if they have less competition (for example, from labs in other countries, as is the case under the CCRA) and they are handed a captive marketplace via country-specific evaluation schemes.

Second, whatever the shortcomings of the CC, it is a strong, broadly-adopted foundation for security that to-date has the support of multiple stakeholders. While it may be improved upon, it is nonetheless better to do one thing in one market that benefits and is accepted in 26 other markets than to do 27 or more expensive testing iterations that will not lead to a 27-fold improvement in security. This is especially true in categories of products that some national schemes have deemed “too complex to evaluate meaningfully.” The alternative clearly isn't per-country testing or per-customer testing, because it is in nobody's interests and not feasible for vendors to do repeated one-off assurance fire-drills for multiple system integrators. Even if the CC is “not sufficient” for all types of testing for all products, it is still a reputable and strong baseline to build upon.

Demand for Higher Assurance

In part, the continuing demand for higher assurance CC evaluations is due to the nature of some of the products: smart cards, for example, are often used for payment systems, where there is a well understood need for “higher proof of security-worthiness.” Also, smart cards generally have a smaller code footprint, fewer interfaces that are well-defined and thus they lend themselves fairly well to more in-depth, higher assurance validation. Indeed, the smart card industry – in a foreshadowing and/or inspiration of CC community Protection Profiles (cPPs), was an early adopter of devising common security requirements and “proof of security claims,” doubtless understanding that all smart card manufacturers - and the financial institutions who are heavy issuers of them - have a vested interest in “shared trustworthiness.” This is a great example of understanding that, to quote Ben Franklin, “We must all hang together or assuredly we shall all hang separately.”

The demand for higher assurance evaluations continues in part because the CC has been so successful. Customers worldwide became accustomed to “EAL4” as the gold standard for most commercial software. “EAL-none”—the direction of new style community Protection Profiles (cPP)—hasn’t captured the imagination of the global marketplace for evaluated software in part because the promoters of “no-EAL is the new EAL4” have not made the necessary business case for why “new is better than old.” An honorable, realistic assessment of “new-style” cPPs would explain what the benefits are of the new approach and what the downsides are as part of making a case that “new is better than old.” Consumers do not necessarily upgrade their TV just because they are told “new is better than old;” they upgrade because they can see a larger screen, clearer picture, and better value for money.

Product Complexity and Evaluations

To the extent security evaluation methodology can be more precise and repeatable, that facilitates more consistent evaluations across the board at a lower evaluation cost. However, there is a big difference between products that were designed to do a small set of core functions, using standard protocols, and products that have a broader swathe of functionality and have far more flexibility as to how that functionality is implemented. This means that it will be impossible to standardize testing across products in some product evaluation categories.

For example, routers use standard Internet protocols (or well-known proprietary protocols) and are relatively well defined in terms of what they do. Therefore, it is far easier to test their security using standardized tests as part of a CC evaluation to, for example, determine attack resistance, correctness of protocol implementation, and so forth. The Network Device Protection Profile (NDPP) is the perfect template for this type of evaluation.

Relational databases, on the other hand, use structured query language (SQL) but that does not mean all SQL syntax in all commercial databases is identical, or that protocols used to connect to the database are all identical, or that common functionality is completely comparable among databases. For example, Oracle was the first relational database to implement commercial row level access control: specifically, by attaching a security policy to a table that causes a rewrite of SQL to enforce additional security constraints. Since Oracle developed (and patented) row level access control, other vendors have implemented similar (but not identical) functionality.

As a result, no set of standard tests can adequately test each vendor’s row level security implementation, any more than you can use the same key on locks made by different manufacturers. Prescriptive (monolithic) testing can work for verifying protocol implementations; it will not work in cases where features are implemented differently. Even worse, prescriptive testing may have the effect of “design by test harness.”

Some national CC schemes have expressed concerns that an evaluation of some classes of products (like databases) will not be “meaningful” because of the size and complexity of these products,[1] or that these products do not lend themselves to repeatable, cross-product (prescriptive) testing. This is true, to a point: it is much easier to do a building inspection of a 1000-square foot or 100-square meter bungalow than of Buckingham Palace. However, given that some of these large, complex products are the core underpinning of many critical systems, does it make sense to ignore them because it’s not “rapid, repeatable and objective” to evaluate even a core part of their functionality? These classes of products are heavily used in the core market sectors the national schemes serve: all the more reason the schemes should not preclude evaluation of them.

Worse, given that customers subject to these CC schemes still want evaluated products, a lack of mutual recognition of these evaluations (thus breaking the CCRA) or negation of the ability to evaluate merely drives costs up. Demand for inefficient and ineffective ad hoc security assurances continues to increase and will explode if vendors are precluded from evaluating entire classes of products that are widely-used and highly security relevant. No national scheme, despite good intentions, can successfully control its national marketplace, or the global marketplace for information technology.

Innovation

One of the downsides of rapid, basic, vanilla evaluations is that it stifles the uptake of innovative security features in a customer base that has a lot to protect. Most security-aware customers (like defense and intelligence customers) want new and innovative approaches to security to support their mission. They also want the new innovations vetted properly (via a CC evaluation).

Typically, a community Protection Profile (cPP) defines the set of minimum security functions that a product in category X does. Add-ons can in theory be done via an extended package (EP) – if the community agrees to it and the schemes allow it. The vendor and customer community should encourage the ability to evaluate innovative solutions through an EP, as long as the EP does not specify a particular approach to a threat to the exclusion of other ways to address the threat. This would continue to advance the state of the security art in particular product categories without waiting until absolutely everyone has Security Feature Y. It’s almost always a good thing to build a better mousetrap: there are always more mice to fend off. Rapid adoption of EPs would enable security-aware customers, many of whom are required to use evaluated products, to adopt new features readily, without waiting for:

a) every vendor to have a solution addressing that problem (especially since some vendors may never develop similar functionality)

b) the cPP to have been modified, and

c) all vendors to have evaluated against the new cPP (that includes the new security feature)

Given the increasing focus of governments on improvements to security (in some cases by legislation), national schemes should be the first in line to support “faster innovation/faster evaluation,” to support the customer base they are purportedly serving.

Last but really first, in the absence of the ability to rapidly evaluate new, innovative security features, customers who would most benefit from using those features may be unable or unwilling to use them, or may only use them at the expense of “one-off” assurance validation. Is it really in anyone’s interest to ask vendors to do repeated one-off assurance fire-drills for multiple system integrators?

Conclusion

The Common Criteria – and in particular, the Common Criteria recognition – form a valuable, proven foundation for assurance in a digital world that is increasingly in need of it. That strong foundation can nonetheless be strengthened by:

1) recognizing and supporting the legitimate need for higher assurance evaluations in some classes of product

2) enabling faster innovation in security and the ability to evaluate it via EPs

3) continuing to evaluate core products that have historically had and continue to have broad usage and market demand (e.g., databases and operating systems)

4) embracing, where apropos, repeatable testing and validation, while recognizing the limitations thereof that apply in some cases to entire classes of products and ensuring that such testing is not unnecessarily prescriptive.

Tuesday Oct 18, 2016

October 2016 Critical Patch Update Released

Oracle today released the October 2016 Critical Patch Update.

This Critical Patch Update provides fixes for a wide range of product families including: Oracle Database Server, Oracle E-Business Suite, Oracle Industry Applications, Oracle Fusion Middleware, Oracle Sun Products, Oracle Java SE, and Oracle MySQL.

Oracle recommends this Critical Patch Update be applied as soon as possible. A summary and analysis of this Critical Patch Update has been published on My Oracle Support (Doc ID 2193091.1)

For More Information:

The Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html

My Oracle Support Note 2193091.11 is located at https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=2193091.1 (MOS account required).

Tuesday Jul 19, 2016

July 2016 Critical Patch Update Released

Oracle today released the July 2016 Critical Patch Update.

This Critical Patch Update provides fixes for a wide range of product families including: Oracle Database Server, Oracle E-Business Suite, Oracle Industry Applications, Oracle Fusion Middleware, Oracle Sun Products, Oracle Java SE, and Oracle MySQL.

Oracle recommends this Critical Patch Update be applied as soon as possible. A summary and analysis of this Critical Patch Update has been published on My Oracle Support (MOS Note 2161607.1)

For More Information:

The Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/security-advisory/cpujul2016-2881720.html

My Oracle Support Note 2161607.1 is located at https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=2161607.1 (MOS account required).

Tuesday Apr 19, 2016

April 2016 Critical Patch Update Released

Oracle today released the April 2016 Critical Patch Update.

This Critical Patch Update provides fixes for a wide range of product families including: Oracle Database Server, Oracle E-Business Suite, Oracle Fusion Middleware, Oracle Sun Products, Oracle Java SE, and Oracle MySQL.

Oracle recommends this Critical Patch Update be applied as soon as possible. A summary and analysis of this Critical Patch Update has been published on My Oracle Support (MOS Note 2126904.1)

For More Information:

The Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/security-advisory/cpuapr2016v3-2985753.html

My Oracle Support Note 2126904.1 is located at https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=2126904.1 (MOS account required).

Wednesday Mar 23, 2016

Security Alert CVE-2016-0636 Released

Oracle released Security Alert CVE-2016-0636 to address a vulnerability affecting Java SE in web browsers on desktops. This vulnerability has received a CVSS Base Score of 9.3 and is remotely exploitable without authentication. A successful exploitation of this vulnerability would typically require an unsuspecting user running an affected version of Java SE to visit a malicious web site.

Oracle recommends customers apply this Security Alert as soon as possible. Oracle recommends that Java home users visit Java.com to ensure that they are running the most recent version of Java SE and that all older versions of Java SE have been completely removed. Oracle further advises against downloading Java from sites other than Java.com as these sites may be malicious.


For more information:

The Advisory for Security Alert CVE-2016-0636 is located at http://www.oracle.com/technetwork/topics/security/alert-cve-2016-0636-2949497.html

Friday Feb 05, 2016

Security Alert CVE-2016-0603 Released

Oracle just released Security Alert CVE-2016-0603 to address a vulnerability that can be exploited when installing Java 6, 7 or 8 on the Windows platform. This vulnerability has received a CVSS Base Score of 7.6.

To be successfully exploited, this vulnerability requires that an unsuspecting user be tricked into visiting a malicious web site and download files to the user's system before installing Java 6, 7 or 8. Though considered relatively complex to exploit, this vulnerability may result, if successfully exploited, in a complete compromise of the unsuspecting user’s system.

Because the exposure exists only during the installation process, users need not upgrade existing Java installations to address the vulnerability. However, Java users who have downloaded any old version of Java prior to 6u113, 7u97 or 8u73, should discard these old downloads and replace them with 6u113, 7u97 or 8u73 or later.

As a reminder, Oracle recommends that Java home users visit Java.com to ensure that they are running the most recent version of Java SE and that all older versions of Java SE have been completely removed. Oracle further advises against downloading Java from sites other than Java.com as these sites may be malicious.

For more information, the advisory for Security Alert CVE-2016-0603 is located at http://www.oracle.com/technetwork/topics/security/alert-cve-2016-0603-2874360.html

 

Tuesday Jan 19, 2016

January 2016 Critical Patch Update Released

Oracle today released the January 2016 Critical Patch Update.  With this Critical Patch Update release, the Critical Patch Update program enters its 11th year of existence (the first Critical Patch Update was released in January 2005).  As a reminder, Critical Patch Updates are currently released 4 times a year, on a schedule announced a year in advance.  Oracle recommends that customers apply this Critical Patch Update as soon as possible.

The January 2016 Critical Patch Update provides fixes for a wide range of product families; including: 

  • Oracle Database
    • None of these database vulnerabilities are remotely exploitable without authentication. 
  • Java SE vulnerabilities
    • Oracle strongly recommends that Java home users visit the java.com web site, to ensure that they are using the most recent version of Java and are advised to remove obsolete Java SE versions from their computers if they are not absolutely needed.
  • Oracle E-Business Suite.
    • Oracle’s ongoing assurance effort with E-Business Suite helps remediate security issues and is intended to help enhance the overall security posture provided by E-Business Suite.

Oracle takes security seriously, and strongly encourages customers to keep up with newer releases in order to benefit from Oracle’s ongoing security assurance effort.  

For more information:

The January 2016 Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/topics/security/cpujan2016-2367955.html

The Oracle Software Security Assurance web site is located at https://www.oracle.com/support/assurance/index.html.

Oracle Applications Lifetime Support Policy is located at http://www.oracle.com/us/support/library/lifetime-support-applications-069216.pdf.

Tuesday Nov 10, 2015

Security Alert CVE-2015-4852 Released

Hello, this is Eric Maurice.   

Oracle released Security Alert CVE-2015-4852 on November 10, 2015 to address the publicly-reported deserialization vulnerability involving Oracle WebLogic Server and the Apache Commons library.   Apache Commons is a project of the Apache Software Foundation, which provides and maintains a widely-used set of Java components.  This library is used by a number of Oracle products as well as many other vendors’ products and open source projects.   

According to Wikipedia, “serialization is the process of translating data structures or object state into a format that can be stored” (in a file, in memory, etc.).   Deserialization is the reverse process (the extraction of the data or object).  The security implications of deserialization have been known for a number of years.  OWASP refers to this kind of vulnerabilities as “deserialization of untrusted data.”  In a nutshell, security vulnerabilities may occur when software developers assume that serialized data can be trusted and is well-formed.    

Vulnerability CVE-2015-4852 has received a CVSS Base Score of 7.5.  If successfully exploited, it can result in remote code execution within Oracle WebLogic Server.  This vulnerability is remotely exploitable without authentication (in instances where the vulnerable component can be accessed by the malicious perpetrator in the absence of other controls such as network access restrictions).   

While permanent fixes are being prepared for Oracle WebLogic Server, this Security Alert provides mitigation instructions.  Please note that the Security Alert also provides instructions for cloud customers on how to obtain more information about the potential impact of this vulnerability in the Oracle Cloud.

For More Information:

The Advisory for Security Alert CVE-2015-4852 is located at http://www.oracle.com/technetwork/topics/security/alert-cve-2015-4852-2763333.html  

Tuesday Oct 20, 2015

October 2015 Critical Patch Update Released

Hi, this is Eric Maurice. Oracle released the October 2015 Critical Patch Update today.  As a reminder, the Critical Patch Update is Oracle’s primary program for the release of security fixes across Oracle product lines. 

Critical Patch Updates are released 4 times a year, in a schedule that is announced a year in advance.  This predictability is intended to provide Oracle customers the ability to plan for the timely application of these security fixes, so that they can maintain their security posture.  In other words, the predictability of the Critical Patch Update schedule is intended to provide Oracle customers with the ability to include security patching in their regular maintenance activities. 

Periodically, Oracle continues to receive reports of malicious exploitation of vulnerabilities for which Oracle has already released fixes.  In some instances, it was reported that malicious attackers were successful because targeted Oracle customers had not applied available security patches.  The problem of the non-application of security fixes is all too common in the industry, particularly around complex enterprise applications, due to their complexity, need for near-complete availability, and need for patch testing and validation prior to deployment in production. Oracle recommends that Critical Patch Updates be applied as soon as possible.  This recommendation is particularly important today because the October 2015 Critical Patch Update include a number of fixes for very severe vulnerabilities. 

The October 2015 Critical Patch Update provides fixes for 154 new security vulnerabilities across a wide range of product families, including: Oracle database, Oracle Fusion Middleware, Oracle Hyperion, Oracle Enterprise Manager, Oracle E-Business Suite, Oracle Supply Chain Products Suite, Oracle PeopleSoft Enterprise, Oracle Siebel CRM, Oracle Industry Applications, including Oracle Communications Applications and Oracle Retail Applications, Oracle Java SE, Oracle Sun Systems Products Suite, Oracle Pillar Axiom, Oracle Linux & Virtualization, and Oracle MySQL.

Out of these 154 new security fixes, 8 are for the Oracle Database.  The most severe of these database vulnerabilities (CVE-2015-4863) has received a CVSS Base Score of 10.0.  This CVSS Base Score of 10.0 denotes a vulnerability that is remotely exploitable without authentication, which, if successfully exploited, can result in a full compromise of the targeted system.  In addition, 3 database vulnerabilities received a CVSS Base Score of 9.0. 

The October 2015 Critical Patch Update provides 15 new security fixes for Oracle Sun Systems Products Suite.  One of the vulnerabilities fixed with this Critical Patch Update (CVE-2015-4915), has received a CVSS Base Score of 10.0.  This vulnerability affects the Integrated Lights Out Manager (a.k.a. ILOM), which is used across a number of products.  In addition to applying the necessary patches as soon as possible, Oracle recommends that customers ensure the ILOM interface be not publicly accessible over the Internet.

This Critical Patch Update also provides 23 security fixes for Oracle Fusion Middleware, 16 of which are remotely exploitable without authentication.  The most severe CVSS Base Score reported for these vulnerabilities is 7.5. 

Oracle Hyperion receives one new security fix with a CVSS Base Score of 1.2.

Oracle Enterprise Manager Grid Control receives 5 new security fixes, 3 of which are remotely exploitable without authentication.  The highest reported CVSS Base Score for the vulnerabilities is 6.8.

This Critical Patch Update also includes a number of fixes for Oracle Applications, including 12 new security fixes for Oracle E-Business Suite (maximum reported CVSS Base Score for E-Business Suite is 6.8), 8 new fixes for Oracle Supply Chain Products Suite (maximum CVSS Base Score of 6.8), 8 new security fixes for Oracle PeopleSoft Enterprise products (maximum CVSS Base Score of 6.8), 1 new security fix for Oracle Siebel CRM (CVSS Base Score of 4.3). 

Oracle Industry Applications receive 14 new security fixes.  9 of these fixes are for Oracle Communications Applications, including 5 new fixes for a vulnerability rated with a CVSS Base Score of 10.0 (CVE-2015-2608 affects a component used on 5 of these products).  Oracle Retail Applications get 4 new fixes and the highest reported CVSS Base Score for these vulnerabilities is 7.5.

Oracle Java SE receives 25 new security fixes, 24 of which are remotely exploitable without authentication.  The highest reported CVSS Base Score for these Java SE vulnerabilities is 10.0.  20 of the Java SE vulnerabilities only affect client deployment of Java SE (e.g., Java in the browser).  The remaining 5 vulnerabilities affect client and server deployments of Java SE.  Java home users should visit the java.com web site, to ensure that they are using the most recent version of Java and remove obsolete JAVA SE versions from their desktop if they are not needed.

Due to the severity of a number of vulnerabilities fixed in this Critical Patch Update, Oracle recommends that the necessary patches be applied as soon as possible.  As of October 19th, the company’s security team didn’t have any indication that any of the most severe vulnerabilities fixed in this Critical Patch Update had been successfully exploited “in the wild” (some of these bugs were discovered internally as part of our ongoing assurance effort).  However, it is our experience that malicious actors will often attempt to reverse-engineer fixes to develop exploit code in an attempt to attack organizations lagging behind in their patching effort.  Keeping up with security releases is important to help preserve a security-in-depth posture.  Fortunately, Critical Patch Update fixes for most Oracle products are cumulative, and this means that the application of the October 2015 Critical Patch Update will resolve not only the new vulnerabilities reported in today’s advisory, but also all the previously-reported security issues affecting the affected Oracle product versions.

For More Information:

The October 2015 Critical Patch Update advisory is located at http://www.oracle.com/technetwork/topics/security/cpuoct2015-2367953.html

The Oracle Software Security Assurance web site is located at http://www.oracle.com/us/support/assurance/overview/index.html 

Thursday Jul 30, 2015

CVSS Version 3.0 Announced

Hello, this is Darius Wiles.

Version 3.0 of the Common Vulnerability Scoring System (CVSS) has been announced by the Forum of Incident Response and Security Teams (FIRST). Although there have been no high-level changes to the standard since the Preview 2 release which I discussed in a previous blog post, there have been a lot of improvements to the documentation.

Soon, Oracle will be using CVSS v3.0 to report CVSS Base scores in its security advisories. In order to facilitate this transition, Oracle plans to release two sets of risk matrices, both CVSS v2 and v3.0, in the first Critical Patch Update (Oracle’s security advisories) to provide CVSS version 3.0 Base scores. Subsequent Critical Patch Updates will only list CVSS version 3.0 scores.

While Oracle expects most vulnerabilities to have similar v2 and v3.0 Base Scores, certain types of vulnerabilities will experience a greater scoring difference. The CVSS v3.0 documentation includes a list of examples of public vulnerabilities scored using both v2 and v3.0, and this gives an insight into these scoring differences. Let’s now look at a couple of reasons for these differences.

The v3.0 standard provides a more precise assessment of risk because it considers more factors than the v2 standard. For example, the important impact of most cross-site scripting (XSS) vulnerabilities is that a victim's browser runs malicious code. v2 does not have a way to capture the change in impact from the vulnerable web server to the impacted browser; basically v2 just considers the impact to the former. In v3.0, the Scope metric allows us to score the impact to the browser, which in v3.0 terminology is the impacted component. v2 scores XSS as "no impact to confidentiality or availability, and partial impact to integrity", but in v3.0 we are free to score impacts to better fit each vulnerability. For example, a typical XSS vulnerability, CVE-2013-1937 is scored with a v2 Base Score of 4.3 and a v3.0 Base Score of 6.1. Most XSS vulnerabilities will experience a similar CVSS Base Score increase.

Until now, Oracle has used a proprietary Partial+ metric value for v2 impacts when a vulnerability "affects a wide range of resources, e.g., all database tables, or compromises an entire application or subsystem". We felt this extra information was useful because v2 always scores vulnerabilities relative to the "target host", but in cases where a host's main purpose is to run a single application, Oracle felt that a total compromise of that application warrants more than Partial. In v3.0, impacts are scored relative to the vulnerable component (assuming no scope change), so a total compromise of an application now leads to High impacts. Therefore, most Oracle vulnerabilities scored with Partial+ impacts under v2 are likely to be rated with High impacts and therefore more precise v3.0 Base scores. For example, CVE-2015-1098 has a v2 Base score of 6.8 and a v3.0 Base score of 7.8. This is a good indication of the differences we are likely to see. Refer to the CVSS v3.0 list of examples for more details on score this vulnerability.

Overall, Oracle expects v3.0 Base scores to be higher than v2, but bear in mind that v2 scores are always relative to the "target host", whereas v3.0 scores are relative to the vulnerable component, or the impacted component if there is a scope change. In other words, CVSS v3.0 will provide a better indication of the relative severity of vulnerabilities because it better reflects the true impact of the vulnerability being rated in software components such as database servers or middleware.


For More Information

The CVSS v3.0 documents are located on FIRST's web site at http://www.first.org/cvss/

Oracle's use of CVSS [version 2], including a fuller explanation of Partial+ is located at http://www.oracle.com/technetwork/topics/security/cvssscoringsystem-091884.html

My previous blog post on CVSS v3.0 preview is located at https://blogs.oracle.com/security/entry/cvss_version_3_0_preview

Eric Maurice's blog post on Oracle's use of CVSS v2 is located at https://blogs.oracle.com/security/entry/understanding_the_common_vulne_2

About

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

Search

Categories
  • Oracle
Archives
« December 2016
SunMonTueWedThuFriSat
    
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
       
Today