Late last year a reporter contacted me who was interested in the
various security features and innovations in Red Hat Enterprise Linux
and Fedora. She particularly wanted to know the dates when each first
made it into a shipping product. In the end the article was published
in a German magazine and was not publically available. It's a shame
to waste the work as I don't think this has ever all been collected
together into one place before, so here is the table. It's possible
I've missed one or two of the features, and I've not broken down the
big things like SELinux where we could talk about the number of
default policies in each release or the number of binaries compiled
PIE, but drop me a mail if you see any issues.

Secondly, we've enhanced support for the severity
classification which is attached to all our security advisories.
In places that display lists
of errata we now display the severity in a separate column, allowing
them to be easily noticed and sorted.

These features are now live and also enhance our public interface to
the Red Hat Network (no login required).

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.

Our usual security audit for Fedora Core 6 is now available. For 20020101 to 20061023 there are a potential 1758 CVE named
vulnerabilities that could have affected FC6 packages. 93% of those are fixed because FC6 includes an upstream version that includes a fix, 1% are still outstanding, and 6% are fixed with a backported patch. Most of those outstanding issues are for low or moderate severity flaws that are not fixed upstream.

There's a new Apache HTTP Server security issue out today, an off-by-one bug that affects the Rewrite module, mod_rewrite. We've not had many serious Apache bugs in some time, in fact the last one of note was four years ago, the Chunked Encoding Vulnerability.

This issue is technically interesting as the off-by-one only lets you write one pointer to the space immediately after a stack buffer. So the ability to exploit this issue is totally dependent on the stack layout for a particular compiled version of mod_rewrite. If the compiler used has added padding to the stack immediately after the buffer being overwritten, this issue can not be exploited, and Apache httpd will continue operating normally. Many older (up to a year or so ago) versions of gcc pad stack buffers on most architectures.

The Red Hat Security Response Team analysed Red Hat Enterprise Linux 3 and Red Hat Enterprise Linux 4 binaries for all architectures as shipped by Red Hat and determined that these versions cannot be exploited. We therefore do not plan on providing updates for this issue.

In contrast, our Fedora Core 4 and 5 builds are vulnerable as the compiler version used adds no stack padding. For these builds, the pointer being overwritten overwrites a saved register and, unfortunately, one that has possible security consequences. It's still quite unlikely we'll see a worm appear for this issue that affects Fedora though: for one thing, the vulnerability can only be exploited when mod_rewrite is enabled and a specific style of
RewriteRule is used. So it's likely to be different on every
vulnerable site (unless someone has some third party product that
relies on some vulnerable rewrite rules). Even then, you still need
to be able to defeat the Fedora Core randomization to be able to
reliably do anything interesting with this flaw.

So, as you can probably tell, I spent a few days this week analysing
assembler dumps of our Apache binaries on some architectures. It was
more fun than expected; mostly because I used to code full-time in
assembler, although that was over 15 years ago.

In the past I've posted timelines of when we found out about issues
and dealt with them in Apache; so for those who are interested:

On Friday 14th July an exploit was widely posted for a vulnerability in the Linux 2.6 kernel, CVE-2006-3626, which attempts to allow a local user to gain root privileges. The exploit relies on the kernel supporting the a.out
binary format.

This vulnerability does not affect Red Hat Enterprise Linux 2.1 or 3 as they are based on 2.4 kernels.

Red Hat Enterprise Linux 4, Fedora Core 4, and Fedora Core 5 do not support the a.out binary format, causing the exploit to fail. We are not currently aware of any way to exploit this vulnerability if a.out binary format is not enabled. In addition, a default installation of these OS enables SELinux in enforcing mode. SELinux also completely blocks attempts to exploit this issue.

The Red Hat Security response team have therefore rated this as having moderate security severity for Enterprise Linux 4. No asynchronous kernel update for this issue is currently planned; the fix for the flaw will be included in some later scheduled update.

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.

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.

Remember allthosereports which compared the number of security vulnerabilities in Microsoft products against Red Hat? Well researchers
have just uncovered proof and an admission that Microsoft silently fix security issues; in one case an advisories states it fixes a single vulnerablity but it actually fixes seven.

Whilst you could perhaps argue that users don't really care if an advisory fixes one critical issue or ten (the fact it contains "at least one" is enough to force them to upgrade), all this time the Microsoft PR engine has been churning out disingenuous articles and doing demonstrations based on vulnerability count comparisons.

In March 2005 we started recording how we first found out about every security issue that we later fixed as part of our bugzilla metadata. The raw data is available. I thought it would be interesting to summarise the findings. Note that we only list the first place we found out about an issue, and for already-public issues this may be arbitrary depending whoever in the security team creates the ticket first.

So from March 2005-March 2006 we had 336 vulnerabilities with source metadata that were fixed in some Red Hat product:

(Note that researchers may seem lower than expected, this is because in many cases the researcher will tell vendor-sec rather than each entity individually, or in some cases researchers like iDefense sometimes do not give us notice about issue prior to them making them public on some security mailing list)