CWE Vulnerability Assessment Report 2014

Last year is almost three months over and we have been busy completing the CWE statistics of our vulnerabilities. The biggest change from the year before is the scale of the data - CWE report for 2013 was based on 37 classified vulnerabilities, whereas last year we classified 617 vulnerabilities in our bugzilla. Out of them 61 were closed with resolution NOTABUG, which means they were either not a security issues, or did not affect Red Hat products. These still include vulnerabilities which affect Fedora or EPEL packages only - narrowing this down to vulnerabilities affecting at least one supported Red Hat product we end up with 479.

The graph below shows the Top 10 weaknesses in Red Hat software. Note the total sum is bigger than overall number of vulnerabilities, as one vulnerability may be result of multiple weaknesses. The most common case is CWE-190 Integer Overflow or Wraparound causing out-of-bounds buffer access problems.

[visualizer id="1684"]

The top spot is taken by cross site scripting with 36 vulnerabilities last year. However, closer examination reveals that despite the count, it was not very common. In fact, two packages had much more XSS flaws that the average: phpMyAdmin with 13 and Openstack (Horizon and Swift) with 7. The standard recommendation to the developers would immediately be to use one of the modern web frameworks, whether it be Ruby on Rails, Django or others.

[visualizer id="1700"]

The second place is occupied by Out-of-bound Read. Again, the distribution of vulnerabilities is not flat among packages, with xorg-x11-server having 9 and chromium-browser 5 vulnerabilities of this type last year. All of the xorg-x11-server come from a single security advisory released on 2014-12-09, which fixed flaws reported by Ilja van Sprundel. The results of his security research of X, which lead to discovery of the flaws, were presented on CCC in 2013. His presentation is a great intoduction into X security problems and is still available.

From the above we could hypothesize that the statistics are dominated by a smaller set of very vulnerable packages, or that certain packages are be prone to certain kinds of weaknesses. The graph below shows a number of vulnerabilities that affected each of the packages - vulnerabilities which did not affected versions of packages we ship are excluded.

[visualizer id="1714"]

Median value of vulnerabilities per package is 1, however, not all packages are equal. Looking at the top 20, all of the packages contain large codebases, some of which are a separate product of an upstream vendor. We should not make a mistake of misinterpreting this graph as Top 20 most vulnerable projects, as it would be more fair to compare apples with apples e.g. kernel (package) with Openstack (which we ship as a product). More honest interpretation would be to see it as a list of packages that increase the attack surface of the system the most when installed.

If we look at statistics per-product, Red Hat Enterprise Linux dominates just by including vast number of packages. The distribution of weaknesses is therefore very close to the overall one show on the first graph above. However, if we look at the top 5 weaknesses in RHEL 5, 6 and 7, we can see a statistically significant drop in number of use after free types of vulnerabilities.

[visualizer id="1690"]

The root cause of this has been traced back to our source code analysis group and the mass scans performed on the Fedora versions prior to RHEL 7 rebase. These scans were performed using a couple of source code analysis tools including Coverity and cppcheck and the warnings were addressed as normal bugs. This explanation is also supported by the decreasing number of found use-after-frees in Fedora from versions 17 to 19, which served as basis for RHEL 7. Interestingly, other weaknesses like buffer access problems and overflows are unaffected, which is probably combination of a) inherent difficulty of their detection via code analysis and b) large number of false positives, making the developers less inclined to address these types of warnings.

[visualizer id="1716"]

The two most common weaknesses in Openshift Enterprise are Information Exposure and Cross Site Scripting. A closer look tells a different story - 5 out of 6 information exposure vulnerabilities were found in Jenkins, shipped as part of the Openshift product. In fact, surprising 21 out of 60 vulnerabilities that affected Openshift product were present in Jenkins. On the other hand, just 9 vulnerabilities were found in core Openshift components.

[visualizer id="1696"]

Interestingly, the distribution of vulnerable components in Openstack is more flat with no component standing out. CWE-400 Uncontrolled Resource Consumption ('Resource Exhaustion') is the most common weakness and all of the vulnerabilities affect core Openstack components. Number of vulnerabilities in Keystone related to session expiration (4) is also surprising, as we haven`t seen many vulnerabilities of that type in other packages last year.

Other products and components also tend to have their specific weaknesses: external entity expansion for Java/JBoss based products, out of bounds reads in Freetype, use after free in Mozilla etc. Overall the depth of the data is much bigger and provides new possibilities for the proactive research. Having more precise data for the feedback loop allowing us to both evaluate past measures and propose future ones is next step towards more efficient proactive security. Unfortunately, the time it takes for any countermeasures to make a dent in statistics is measured in releases, so this data will become much more interesting as they change in time.