mark :: blog

<< prev [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 ] next >>


Red Hat has shipped products with randomization, stack protection, and other security mechanisms turned on by default since 2003. Vista recently shipped with similar protections and I read today an article about how the Microsoft Security Response Team were not treating Vista any differently when rating the severity of security issues. The Red Hat Security Response team use a similar guide for classification and I thought it would be worth clarifying how we handle this very situation.

We rate the impact of individual vulnerabilities on the same four point scale, designed to be an at-a-glance guide to how worried Red Hat is about each security issue. The scale takes into account the potential risk of a flaw based on a technical analysis of the exact flaw and it's type, but not the current threat level. Therefore the rating given to an issue will not change if an exploit or worm is later released for a flaw, or if one is available before release of a fix.

For the purpose of evaluating severities, our protection technologies fall into roughly three categories:

  1. Security innovations that completely block a particular type of security flaw. An example of this is Fortify Source. Given a particular vulnerability we can evaluate if the flaw would be caught at either compile time or run time and blocked. Because this is deterministic, we will adjust the security severity of an issue where we can prove it would not be exploitable.

  2. Security innovations that should block a particular security flaw from being remotely exploitable. Examples of this would be support for NX, Randomisation, and Stack canaries. Although these technologies can reduce the likelyhood of exploiting certain types of vulnerabilities, we don't take them into account and don't downgrade the security severity.

  3. Security innovations that try to contain an exploit for a vulnerability. I'm thinking here of SELinux. An attacker who can exploit a flaw in any of the remotely accessible daemons protected by a default SELinux policy will find themselves tightly constrained by that policy. We do not take SELinux into account when setting the security severity.

I've not been keeping a list of vulnerabilities that are deterministically blocked, but I have a couple of examples I recall where we did alter the severity:


Enterprise Linux 5 has been consuming much of my time over the last few months. From work on the signing server and new key policy, through testing of the new update mechanism, and continuing audits of outstanding vulnerabilities. Yesterday was release day, and we also pushed security updates for 12 packages in Enterprise Linux 5.

It may seem surprising that we release security updates for a product exactly at the same time we release it, but product development is frozen for some weeks before we release the product to give time testing from the various Quality Engineering teams as well as release engineering work. During that time we want to minimise the number of changes that will invalidate the overall testing, so we instead prepare the changes as updates. Since the vulnerabilities being fixed are already public, we push the updates out as soon as we can; holding them off to some scheduled monthly date would just increase customer risk.

Security advisories for Enterprise Linux 5 are available from the usual places, on the web, sent to the enterprise-watch-list mailing list, and via OVAL definitions. Red Hat Network subscribers can also get customized mails for the subset of issues that affect the packages they actually have installed.

For me, what's going to be interesting to watch over the next few months is how specific vulnerabilities and exploits affect this platform. Red Hat Enterprise Linux 5 packages are compiled both with Fortify Source and stack smashing protection in addition to all the security features that were in version 4. I'll be reporting on what difference this makes through the year.


We're changing the package signing key we use for all new Red Hat products.

Since 1999, all RPM packages in Red Hat products have been gpg signed by the master key "Red Hat, Inc <security@redhat.com>" (keyid DB42A60E). I'll call this the legacy signing key for the rest of this article. This signature is one of two security mechanisms we use to ensure that customers can trust the installation of packages and their updates. The other is that the update client, up2date, checks the SSL server signature when it connects to the Red Hat Network to ensure that it only talks to official Red Hat servers; so removing the possibility of a man-in-the-middle attack.

From 2007, all new products will be signed with a different master key, "Red Hat, Inc. (release key) <security@redhat.com>" (keyid 37017186). This includes Red Hat Enterprise Linux 5, and any other new products that use RPM packages. The exception to this rule is that any new layered products designed for older versions of Enterprise Linux will still use the legacy key: so for example, a new version of the Application Stack for Red Hat Enterprise Linux 4 will be signed with the legacy key.

The legacy key hasn't been compromised so why change keys? It's all to do with the way the keys are stored and managed internal to Red Hat. The legacy key is a software key and so the key material exists, protected by a passphrase, on a hard disk. When packages need to be signed one of the Red Hat authorised signers manually runs a signing command, this calls rpm --resign which asks for the passphrase then in turn calls out to GNUpg to do the actual signature creation. So the authorised signers not only had the ability to sign with the key, but they also have the ability to read the key material. In theory this means that a malicious internal signer could copy the key, take it away with them, and sign whatever and whenever they wanted. Or, more likely, a clever intruder who gained access to our internal network could perhaps capture the key and passphrase, compromising the key. The risks mean we've had to be really careful who has signing privileges with the legacy key and how the key signing is handled.

The new key, in contrast, was created in a hardware cryptographic device which does not allow the unprotected key material to be exported. This means we can give authorised signers the ability to sign with the key, but no one can ever can get access to the key material itself. This is an important distinction. If for example a current authorised signer switches roles and is no longer responsible for package signing we can instantly revoke their rights and know that they no longer have the ability to sign any more packages with that key.

There was no off-the-shelf solution available for hardware-based RPM key management, so we developed one internally ourselves. We used nCipher nShield hardware security modules (FIPS 140-2 validated) for the key protection along with custom patches I developed to interface RPM/GNUpg to the unit. At the same time we also introduced an extra layer of abstraction to the signing software, so we can authorize signers using their existing internal kerberos credentials.

So, as a customer, you won't really notice any difference. For Red Hat Enterprise Linux 5 you'll find the public keys on our website as well as in the /etc/pki/rpm-gpg/ directory and you'll be prompted when updating or installing new packages for the first time to import that new public key.

This change basically makes it easier for us to protect our signing key and reduce the risk of it being compromised, therefore reducing the chances we'll need to change the key and involve customer effort in the future.


Back in July 1999 I visited Tokyo on a business trip for C2Net; we were trying to break into the Japanese market with Stronghold. I spent a spare day shopping and exploring and although having my film camera with me didn't get around to taking many pictures. I lost the camera, found it, lost it again, and came across it this weekend with it's film still inside, half used and figured it was worth a few pounds to see if the film could be developed. The photos didn't turn out too bad for a cheap 35mm colour film that's been exposed and unprocessed for over 7 years! I'm most happy about the photo I took of the specialist Pingu character shop in which I spent a lot of Yen. Wonder if it's still there....


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.

  Fedora Core Red Hat Enterprise Linux
123456 34
2003Nov2004May2004Nov2005Jun2006Mar2006Oct 2003Oct2005Feb
Default requires signed updates YYYYYY YY
NX emulation using segment limits by default YYYYYY since 2004SepY
Support for Position Independent Executables (PIE) YYYYYY since 2004SepY
ASLR for Stack/mmap by default YYYYYY since 2004SepY
ASLR for vDSO (if vDSO enabled) no vDSOYYYYY no vDSOY
Restricted access to kernel memory by default  YYYYY  Y
NX by default for supported processors/kernels  since 2004JunYYYY since 2004SepY
Support for SELinux  YYYYY  Y
SELinux default enabled with targetted policies   YYYY  Y
glibc heap/memory checks by default   YYYY  Y
Support for FORTIFY_SOURCE, used on selected packages   YYYY  Y
All packages compiled using FORTIFY_SOURCE    YYY   
Support for ELF Data Hardening    YYY  Y
All packages compiled with stack smashing protection     YY   
Pointer encryption      Y   
CVE compatible        YY
OVAL compatible        since 2006Maysince 2006May

New: Updated version from 7th January 2008


Red Hat Network got a minor update last night which added a couple of new security features we've been working on: 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.

The full details broken out by CVE name are available as at GOLD (fixed) or latest status (updated daily)


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:

20060721-23:29 Mark Dowd forwards details of issue to security@apache.org
20060722-07:42 Initial response from Apache security team
20060722-08:14 Investigation, testing, and patches created
20060724-19:04 Negotiated release date with reporter
20060725-10:00 Notified NISCC and CERT to give vendors heads up
20060727-17:00 Fixes committed publically
20060727-23:30 Updates released to Apache site
20060828       Public announcement from Apache, McAfee, CERT, NISCC
Here is the patch against 2.0, the patch against 1.3 or 2.2 is almost identical.


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.

For more technical details of this issue please see bz#198973

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.

<< prev [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 ] next >>

Hi! I'm Mark Cox. This blog gives my thoughts and opinions on my security work, open source, fedora, home automation, and other topics.