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:
- 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.
- 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.
- 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
- In October 2005 a buffer overflow flaw
was found in the authentication
code of wget. On Fedora Core 4 this flaw was not exploitable it was
caught by Fortify Source.
- In August 2004, a double-free flaw in
MIT Kerberos KDC was announced.
For users of Red Hat
Enterprise Linux 4 users we were able to downgrade the severity of
this flaw from critical as glibc hardening
prevented this double-free flaws being exploited. The flaw was
rated important as it could still lead to a remote denial of service