We now have an official Red Hat Security Blog, and you'll find all my future reports and discussions about security metrics there. In the meantime here are a few already published articles:
- How
Red Hat rates JBoss security flaws
- CWE
Vulnerability Assessment Report
- Welcome to the Red Hat Security Blog
Red Hat Enterprise Linux 5.8 was released today (February 2012), seven months since the release of 5.7 in July 2011. So let's use this opportunity to take a quick look back over the vulnerabilities and security updates made in that time, specifically for Red Hat Enterprise Linux 5 Server.
Red Hat Enterprise Linux 5 is coming up to its fifth year since release, and is supported for another five years, until 2017.
Errata count
The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 5 Server if you had installed 5.7, up to and including the 5.8 release, broken down by severity. It's split into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve quite a bit of manual effort to select every one). For a given installation, the number of package updates and vulnerabilities that affected you will depend on exactly what packages you have installed or removed.
So, for a default install, from release of 5.7 up to and including 5.8, we shipped 42 advisories to address 118 vulnerabilities. 4 advisories were rated critical, 13 were important, and the remaining 25 were moderate and low.
Or, for all packages, from release of 5.7 up to and including 5.8, we shipped 71 advisories to address 177 vulnerabilities. 7 advisories were rated critical, 16 were important, and the remaining 48 were moderate and low.
Critical vulnerabilities
The 7 critical advisories addressed 20 critical vulnerabilities across 4 different packages:
- An update to OpenJDK 6 Java Runtime Environment, (October 2011) where a web site hosting a malicious Java applet could potentially run arbitrary code as the user.
- An update to the MIT krb5 telnet daemon (December 2011) where a remote attacker who can access the telnet port of a target machine could use this flaw to execute arbitrary code as root. Note that the krb5 telnet daemon is not installed or enabled by default, and the default firewall rules block remote access to the telnet port. This flaw did not affect the more commonly used telnet daemon distributed in the telnet-server package.
- Updates to PHP and PHP 5.3 (February 2012) where a remote attacker could send a specially-crafted HTTP request to cause the PHP interpreter to crash or, possibly, execute arbitrary code. This flaw was caused by the fix for CVE-2011-4885.
- Three updates to Firefox (August 2011, September 2011, November 2011) where a malicious web site could potentially run arbitrary code as the user running Firefox.
Updates to correct 19 out of the 20 critical vulnerabilities were available via Red Hat Network either the same day or the next calendar day after the issues were public. The update to krb5 took 2 calendar days because it was public on Christmas day.
Overall, for Red Hat Enterprise Linux 5 since release until 5.8, 98% of critical vulnerabilities have had an update available to address them available from the Red Hat Network either the same day or the next calendar day after the issue was public.
Other significant vulnerabilities
Although not in the definition of critical severity, also of interest during this period were a couple of remote denial of service flaws that were easily exploitable:
- A flaw in BIND, CVE-2011-4313, fixed by RHSA-2011:1458 (bind) and RHSA-2011:1459 (bind97). A remote attacker could use this flaw to cause BIND to crash.
- A flaw in Apache HTTP Server, CVE-2011-3192, fixed by RHSA-2011:1245. A remote attacker could use this flaw to cause httpd to use an excessive amount of memory and CPU time.
In addition, updates to Firefox, NSS, and Thunderbird were made to blacklist a compromised Certificate Authority.
Previous update releases
To compare these statistics with previous update releases we need to take into account that the time between each update release is different. So looking at a default installation and calculating the number of advisories per month gives the following chart:
This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn't really useful for comparisons with other major versions, distributions, or operating systems -- for example, a default install of Red Hat Enterprise Linux 4AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, timescales, and severity range of interest.
See also: 5.7, 5.6, 5.5, 5.4, 5.3, 5.2, and 5.1 risk reports.
Red Hat Enterprise Linux 5.7 was released last week (July 2011), six months since the release of 5.6 in January 2011. So let's use this opportunity to take a quick look back over the vulnerabilities and security updates made in that time, specifically for Red Hat Enterprise Linux 5 Server.
Errata count
The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 5 Server if you had installed 5.6, up to and including the 5.7 release, broken down by severity. It's split into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve quite a bit of manual effort to select every one). For a given installation, the number of package updates and vulnerabilities that affected you will depend on exactly what packages you have installed or removed.
So, for a default install, from release of 5.6 up to and including 5.7, we shipped 27 advisories to address 109 vulnerabilities. 3 advisories were rated critical, 12 were important, and the remaining 12 were moderate and low.
Or, for all packages, from release of 5.6 to and including 5.7, we shipped 58 advisories to address 172 vulnerabilities. 4 advisories were rated critical, 20 were important, and the remaining 34 were moderate and low.
Critical vulnerabilities
The 4 critical advisories addressed 34 critical vulnerabilities across just 2 different packages:
- An update to OpenJDK 6 Java Runtime Environment, (June 2011) where a web site hosting a malicious Java applet could potentially run arbitrary code as the user.
- Three updates to Firefox (March 2011, April 2011, June 2011) where a malicious web site could potentially run arbitrary code as the user running Firefox.
Updates to correct all of the 34 critical vulnerabilities were available via Red Hat Network either the same day or the next calendar day after the issues were public.
Overall, for Red Hat Enterprise Linux 5 since release until 5.7, 97% of critical vulnerabilities have had an update available to address them available from the Red Hat Network either the same day or the next calendar day after the issue was public.
Other significant vulnerabilities
Although not in the definition of critical severity, also of interest during this period were a couple of flaws that were easily exploitable:
- A flaw in dhcp, CVE-2011-0997, fixed by RHSA-2011:0428, where a malicious DHCP server could send a response that could lead to arbitrary code execution on connecting clients.
- A flaw in glibc, CVE-2011-0536, fixed by RHSA-2011:0412, where a local user could gain root privileges.
In addition, updates to Firefox and NSS were made to blacklist a number of compromised SSL certificates.
Previous update releases
To compare these statistics with previous update releases we need to take into account that the time between each update release is different. So looking at a default installation and calculating the number of advisories per month gives the following chart:
This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn't really useful for comparisons with other major versions, distributions, or operating systems -- for example, a default install of Red Hat Enterprise Linux 4AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, timescales, and severity range of interest.
See also: 5.5 to 5.6, 5.4 to 5.5, 5.3 to 5.4, 5.2 to 5.3, 5.1 to 5.2, and 5.0 to 5.1 risk reports.
Red Hat Enterprise Linux 5.6 was released last week (January 2011), nearly ten months since the release of 5.5 in March 2010. So let's use this opportunity to take a quick look back over the vulnerabilities and security updates made in that time, specifically for Red Hat Enterprise Linux 5 Server.
Errata count
The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 5 Server if you had installed 5.5, up to and including the 5.6 release, broken down by severity. It's split into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve a bit of manual effort to select every one). For a given installation, the number of package updates and vulnerabilities that affected you will depend on exactly what you have installed or removed.
So, for a default install, from release of 5.5 up to and including 5.6, we shipped 57 advisories to address 206 vulnerabilities. 10 advisories were rated critical, 27 were important, and the remaining 20 were moderate and low.
Or, for all packages, from release of 5.5 to and including 5.6, we shipped 80 advisories to address 300 vulnerabilities. 12 advisories were rated critical, 34 were important, and the remaining 34 were moderate and low.
Critical vulnerabilities
The 12 critical advisories addressed 49 critical vulnerabilities across just 3 different packages:
- An update to the Exim Internet Mailer, (December 2010), where an unauthenticated remote attacker could run arbitrary code as root on a server. Exim is not a default package or enabled by default. There is a public exploit for this issue which worked on Red Hat Enterprise Linux 5.
- Two updates over three advisories to Samba, (June 2010 for Samba 3.0 and Samba 3.3, September 2010 for Samba 3.0 and Samba 3.3), where a malicious client could send a specially-crafted SMB packet to the Samba server, potentially resulting in arbitrary code execution with the privileges of the Samba server. I'm not aware of any working public exploits for these issues.
- Eight updates to Firefox (March 2010, June 2010, 20 July 2010, 23 July 2010, September 2010, 19 October 2010, 27 October 2010, December 2010) where a malicious web site could potentially run arbitrary code as the user running Firefox.
Updates to correct 48 out of the 49 critical vulnerabilities were available via Red Hat Network either the same day or the next calendar day after the issues were public. The update to fix Exim took 3 calendar days from the date of the report to the Exim developers.
Overall, for Red Hat Enterprise Linux 5 since release until 5.6, 97% of critical vulnerabilities have had an update available to address them available from the Red Hat Network either the same day or the next calendar day after the issue was public.
Other significant vulnerabilities
Although not in the definition of critical severity, also of interest during this period were several kernel flaws that where an local user could gain root privileges. The following had publicly available exploits:- A fix for CVE-2010-2240 was provided by RHSA-2010-0661 (August 2010). The public exploit did not work against Red Hat Enterprise Linux 5, but it may be possible to create one that does.
- A fix for CVE-2010-3081 was provided by RHSA-2010-0704 (September 2010). The public exploit worked against Red Hat Enterprise Linux 5
- A fix for CVE-2010-3904 was provided by RHSA-2010-0792 (October 2010). The public exploit did not work against Red Hat Enterprise Linux 5 but it is possible to create one that does.
Previous updates
To compare these statistics with previous update releases we need to take into account that the time between each update is different. So looking at a default installation and calculating the number of advisories per month gives the following chart:
This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn't really useful for comparisons with other major versions, distributions, or operating systems -- for example, a default install of Red Hat Enterprise Linux 4AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, timescales, and severity range of interest.
See also: 5.4 to 5.5, 5.3 to 5.4, 5.2 to 5.3, 5.1 to 5.2, and 5.0 to 5.1 risk reports.
Red Hat Enterprise Linux 5.5 was released at the end of March 2010, just under 7 months since the release of 5.4 in September 2009. So let's use this opportunity to take a quick look back over the vulnerabilities and security updates we've made in that time, specifically for Red Hat Enterprise Linux 5 Server.
Errata count
The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 5 Server if you had installed 5.4, up to and including the 5.5 release, broken down by severity. I've split it into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve a bit of manual effort to select every one). For a given installation, the number of package updates and vulnerabilities that affected you will depend on exactly what you have installed or removed.
So for a default install, from release of 5.4 up to and including 5.5, we shipped 52 advisories to address 140 vulnerabilities. 5 advisories were rated critical, 14 were important, and the remaining 33 were moderate and low.
Or, for all packages, from release of 5.4 to and including 5.5, we shipped 75 advisories to address 187 vulnerabilities. 6 advisories were rated critical, 18 were important, and the remaining 51 were moderate and low.
Critical vulnerabilities
The 6 critical advisories were for 3 different packages. Given the nature of the flaws, ExecShield protections in RHEL5 should make exploiting the memory flaws harder.
- Four updates to Firefox (September 2009, October 2009, December 2009, February 2010) where a malicious web site could potentially run arbitrary code as the user running Firefox.
- An update to kdelibs (November 2009), where a malicious web site could potentially run arbitrary code as the user running the Konqueror browser. kdelibs is not a default installation package.
- An update to krb5, the Kerberos network authentication system (January 2010), where a remote KDC client could cause a crash or run arbitrary code as root. This issue only affected users that have configured and enabled krb5.
Updates to correct 24 out of the 25 critical vulnerabilities were available via Red Hat Network either the same day, or up to one calendar day after the issues were public. The update to fix Konqueror took us 4 calendar days.
Overall, for Red Hat Enterprise Linux 5 since release to date, 98% of critical vulnerabilities have had an update available to address them available from the Red Hat Network either the same day or the next calendar day after the issue was public.
Other significant vulnerabilities
Red Hat Enterprise Linux since 5.2 contained backported patches from the upstream Linux kernel to add the ability to restrict unprivileged mapping of low memory, designed to mitigate NULL pointer dereference flaws. In the last risk report we mentioned it was found that this protection was not sufficient, as a system with SELinux enabled was more permissive in allowing local users in the unconfined_t domain to map low memory areas even if the mmap_min_addr restriction is enabled. This is CVE-2009-2695 and was addressed in a kernel update in November 2009.
Previous updates
To compare these statistics with previous update releases we need to take into account that the time between each update is different. So looking at a default installation and calculating the number of advisories per month gives the results illustrated by the following chart:
This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn't really useful for comparisons with other versions, distributions, or operating systems -- for example, a default install of Red Hat Enterprise Linux 4AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, timescales, and severity range of interest.
See also: 5.3 to 5.4, 5.2 to 5.3, 5.1 to 5.2, and 5.0 to 5.1 risk reports.
Red Hat Enterprise Linux 5.4 was released today, just over 7 months since the release of 5.3 in January 2009. So let's use this opportunity to take a quick look back over the vulnerabilities and security updates we've made in that time, specifically for Red Hat Enterprise Linux 5 Server.
Errata count
The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 5 Server as if you installed 5.3, up to and including the 5.4 release, broken down by severity. I've split it into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve a bit of manual effort to select every one). For a given installation, the number of package updates and vulnerabilities that affected you will depend on exactly what you have installed or removed.
So for a default install, from release of 5.3 up to and including 5.4, we shipped 51 advisories to address 166 vulnerabilities. 8 advisories were rated critical, 18 were important, and the remaining 25 were moderate and low.
Or, for all packages, from release of 5.3 to and including 5.4, we shipped 78 advisories to address 251 vulnerabilities. 9 advisories were rated critical, 28 were important, and the remaining 41 were moderate and low.
Critical vulnerabilities
The 9 critical advisories were for just 3 different packages. In all the cases below, given the nature of the flaws, ExecShield protections in RHEL5 should make exploiting these memory flaws harder.
- Seven updates to Firefox (February, March 4th, March 27th, April 21st, April 27th, June, July ) where a malicious web site could potentially run arbitrary code as the user running Firefox.
- An update to kdelibs (June), where a malicious web site could potentially run arbitrary code as the user running the Konqueror browser. kdelibs is not a default installation package.
- An update to the NSS library (July), where a service could present a malicious SSL certificate causing a heap overflow which could potentially run arbitrary code as the user running a browser such as Firefox.
Updates to correct all of these critical vulnerabilities were available via Red Hat Network either the same day, or up to one calendar day after the issues were public.
In fact for Red Hat Enterprise Linux 5 since release and to date, every critical vulnerability has had an update available to address it available from the Red Hat Network either the same day or the next calendar day after the issue was public.
Other significant vulnerabilities
Although not in the definition of critical severity, also of interest during this period were several NULL pointer dereference kernel issues. NULL pointer dereference flaws in the Linux kernel can often be easily abused by a local unprivileged user to gain root privileges through the mapping of low memory pages and crafting them to contain valid malicious instructions:
- CVE-2009-2698 was public on August 24th and a working privilege escalation exploit was published about a week later. This issue was addressed for Red Hat Enterprise Linux 5 by a kernel update on August 24th.
- CVE-2009-2692 was public on August 13th and a working privilege escalation exploit was published the same day. This issue was addressed for Red Hat Enterprise Linux 5 by a kernel update on August 24th.
- CVE-2009-1897 was public on July 16th along with a working privilege escalation exploit. This issue affected only beta versions of the Red Hat Enterprise Linux 5.4 kernel and it was addressed prior to the release of Red Hat Enterprise Linux 5.4.
Red Hat Enterprise Linux since 5.2 has contained backported patches from the upstream Linux kernel to add the ability to restrict unprivileged mapping of low memory, designed to mitigate NULL pointer dereference flaws. However it was found that this protection was not sufficient, as a system with SELinux enabled is more permissive in allowing local users in the unconfined_t domain to map low memory areas even if the mmap_min_addr restriction is enabled. This is CVE-2009-2695 and will be addressed in a future kernel update.
Mitigations
Red Hat Enterprise Linux 5 shipped with a number of security technologies designed to make it harder to exploit vulnerabilities and in some cases block exploits for certain flaw types completely. From 5.3 to 5.4 there were three flaws blocked that would otherwise have required critical updates:
- CVE-2009-0692, a stack buffer overflow flaw in dhclient. FORTIFY_SOURCE protection detects the overflow and causes dhclient to exit with no security consequence. No security update for users of Red Hat Enterprise Linux 5 was needed.
- CVE-2009-1252 a buffer overflow flaw in NTP caught by FORTIFY_SOURCE. We issued an update as a remote attacker could still cause a denial of service.
- CVE-2009-0846, a uninitialized pointer free in krb5. glibc provides a hardened malloc/free implementation which mitigates the exploitability of this flaw, however we issued an update as a remote attacker could still cause a denial of service.
Previous updates
To compare these statistics with previous update releases we need to take into account that the time between each update is different. So looking at a default installation and calculating the number of advisories per month gives the results illustrated by the following chart:
This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn't really useful for comparisons with other versions, distributions, or operating systems -- for example, a default install of Red Hat Enterprise Linux 4AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, timescales, and severity range of interest.
See also: 5.2 to 5.3, 5.1 to 5.2, and 5.0 to 5.1 risk reports.
The National Vulnerability Database provides a public severity rating for all CVE named vulnerabilities, "Low" "Medium" and "High", which they generate automatically based on the CVSS score their analysts calculate for each issue. I've been interested for some time to see how well those map to the severity ratings that Red Hat give to issues. We use the same ratings and methodology as Microsoft and others use, assigning "Critical" for things that have the ability to be remotely exploited automatically through "Important", "Moderate", to "Low".
Given a thundery Sunday afternoon I took the last 12 months of all possible vulnerabilities affecting Red Hat Enterprise Linux 4 (from 126 advisories across all components) from my metrics page and compared to NVD using their provided XML data files. The result broke down like this:
| Red Hat |
| ||||
| NVD |
|
So that looked okay on the surface; but the diagram above implies that all the issues Red Hat rated as Critical got mapped in NVD to High. But that's not actually the case, and when you look at the breakdown you get this result: (in number of vulnerabilities)
| NVD: High |
|
| NVD: Moderate |
|
| NVD: Low |
|
That shows nearly half of the issues that NVD rated as High actually only affected Red Hat with Moderate or Low severity. Given our policy is to fix the things that are Critical and Important the fastest (and we have a pretty impressive record for fixing critical issues), it's no wonder that recent vulnerability studies that use the NVD mapping when analysing Red Hat vulnerabilities have some significant data errors.
I wasn't actually surprised that there are so many differences: my hypothesis is that many of the errors are due to the nature of how vulnerabilities affect open source software. Take for example the Apache HTTP server. Lots of companies ship Apache in their products, but all ship different versions with different defaults on different operating systems for different architecture compiled with different compilers using different compiler options. Many Apache vulnerabilities over the years have affected different platforms in significantly different ways. We've seen an Apache vulnerability that leads to arbitrary code execution on older FreeBSD, that causes a denial of service on Windows, but that was unexploitable on Linux for example. But it has a single CVE identifier.
So if you're using a version of the Apache web server you got with your Red Hat Enterprise Linux distribution then you need to rely on Red Hat to tell you how the issue affects the version they gave you -- in the same way you rely on them to give you an update to correct the issue.
I did also spot a few instances where the CVSS score for a given vulnerability was not correctly coded. CVSS version 2 was released last week and once NVD is based on the new version I'll redo this analysis and spend more time submitting corrections to any obvious mistakes.
But in summary: for multi-vendor software the severity rating for a given vulnerability may very well be different for each vendors version. This is a level of detail that vulnerability databases such as NVD don't currently capture; so you need to be careful if you are relying on the accuracy of third party severity ratings.
Earlier this month, Steve Christey posted a draft report of the Vulnerability Type Distributions in CVE. The report notices, amongst other things, some differences between open and closed source vendors. I thought it would be more interesting to focus just on one of our released distributions to see if it made a difference to the trends. Steve kindly provided some reports based on a list of CVE names I gave him, and this led to the analysis and these two graphs.
First, the Vulnerability Type Distribution graph. This is not really a big surprise, the most common vulnerabilities we fix are buffer overflows. Technologies such as ExecShield (PIE, support for NX, FORTIFY_SOURCE and so on) were designed specifically to reduce the risk of being able to exploit this flaw type. Secondly, compared to the industry as a whole we fix far less web application flaws such as cross-site scripting or SQL injection. This result is to be expected as most of these are in PHP web applications we don't ship in our distributions.
Earlier this month Red Hat started publishing Open Vulnerability and Assessment Language (OVAL) definitions for Red Hat Enterprise Linux security issues and today we obtained official compatibility. But what are these definitions, how do you use them, and why are they important?
One of the goals of Red Hat Enterprise Linux is to maintain backward compatibility of the packages we ship where possible. This goal means making sure that when we release security updates to fix vulnerabilities that we include just the security fixes in isolation, a process known as backporting. Backporting security fixes has the advantage that it makes installing updates safer and easier for customers, but has the disadvantage that it can cause confusion to people unfamiliar with the process who try to use the version number of a particular piece of software to determine it's patch status.
In 2002, Red Hat started publishing Common Vulnerability and Exposures (CVE) vulnerability identifiers on every security advisory in order to make it easy to see what we fixed and how. Customers need only know the CVE identifiers for the vulnerabilities they are interested in and can then find out quickly and easily which of our updates addressed that particular vulnerability. CVE is now used on security advisories from nearly all the major vendors.
Red Hat has a single common mechanism for keeping systems up to date with security errata, the Red Hat Network. The Red Hat Network looks at a customers machines to determine which updates are required and gives anything from a customised notification that an update is available through to automated installation. Third party patch auditing tools don't have such an easy time figuring out what up dates are required: they have to maintain their own list of Red Hat package versions against vulnerability names. As this list is different for each operating system version from each potential vendors, these tools are prone to many errors and lag behind our updates.
We've also found customers that query the Red Hat Network errata pages directly to gather information about our security advisories and put them into a format they can integrate with their own processes. Many customers take feeds of vulnerability data, usually in some XML format, from third party security vulnerability companies.
MITRE recognised both of these issues a number of years ago when they founded the Open Vulnerability and Assessment Language project, OVAL in 2002. The aim of OVAL is to provide a language for defining how to test for vulnerabilities and system configuration errors in an open and cross-platform manner. Red Hat was a founding board member of the OVAL project as part of our overall commitment to security quality.
So Red Hat now publishes OVAL 5 definitions for our Red Hat Enterprise Linux 3 and 4 security advisories. Each security advisory gets a separate XML OVAL file which defines the steps needed to test if an update is required for the target system. In an ideal world every Red Hat Enterprise Linux system would be consuming every update from Red Hat Network automatically, but for those that don't or where systems have been disconnected for some time, these definitions can help determine the patch status. In addition, these definitions contain selected info rmation from our advisories which can be combined with vulnerability feeds from third parties.
Red Hat OVAL patch definitions contain:
- A link to the original advisory
- CVE references for all the vulnerabilities fixed by the advisory
- References into our public bug tracking database
- The severity of the advisory
- A short description abstract taken from the advisory text
- For each Enterprise Linux version, a list of the packages and versions required to determine if the update is required
The actual OVAL definitions themselves are available from https://www.redhat.com/oval/ and are public within a couple of hours of an advisory being pushed to the Red Hat Network. OVAL definitions for all previous Red Hat Enterprise Linux 3 and 4 advisories are also available. At present we do not ship OVAL tools such as a definition interpreter, but there are severalopen-source and commercial OVAL-compatible tools available.
For the future we encourage other vendors to publish definitive OVAL definitions for their products too, and we hope to work on compatibility testing with other operating system and tool vendors.
More information about the make-up of the OVAL patch definitions can be found at the MITRE OVAL site. An FAQ about our implementation and where to contact us with comments or questions is also available.
I've just finished a run to update Red Hat security advisories from CAN- to CVE- names, 180 advisories were updated.
In security advisories we include references to the MITE Common Vulnerabilities and Exposures dictionary for each vulnerability, you'll see us link to names like CAN-2004-0111. The CAN- prefix shows that the entry is a candidate that has been proposed for inclusion in the dictionary. From time to time the editorial board (of which Red Hat is a member) votes on the candidates and the ones that pass get promoted to full CVE- prefixes, but only the prefix changes. In the recent round of voting I accepted or modified 145 entries. Yesterday the CVE project promoted 480 CAN names to CVE names. We've updated our mappings so that if you look on the Red Hat Network or online at our advisory texts you'll see reference to the promoted names. We've not gone through and altered the text, or are we likely to, so you might still see texts refer to CAN-2004-0111 for example, but all the links are magically updated to CVE-2004-0111.
