One of the top reasons that machines fall foul to security exploits is when they are not kept up to date with security issues. So it follows that to protect users a vendor needs to make security updates as easy and painless as possible. At conferences I highlight that one of the important things a Linux distribution gives you are updates across your entire stack - you don't need to use one system to grab your OS updates, another to get updates to your office application, the built-in update system in your Money tool, a manual update for Flash, and so on.
Red Hat released updates to PHP to correct this vulnerability for Red Hat Enterprise Linux 3 and 4 in July 2005. Red Hat Enterprise Linux 2.1 was not affected by this vulnerability. Fedora Core 4 and Fedora Core 3 also got updates in July.
Our analysis showed that the default SELinux targeted policy on Enterprise Linux 4 would have blocked the specific instances of this worm seen so far, but is not sufficient to block a worm written differently from exploiting this vulnerability if left unpatched. Time to make sure all your servers are up2date!
The kernel accounted for 14% of all the vulnerabilities fixed, followed closely by mozilla (11%), ethereal (9%), squid (4%), gaim (4%), httpd (3%), php (3%), krb5 (2%).
In fact, half of all the vulnerabilities fixed are in only those 8 packages, and just 20 packages comprise of two-thirds of all vulnerabilities.
But we fix a large number of security issues rated as 'low' severity which can influence the data. So if we weight vulnerabilities by severity (I used a metric of "Critical *100 + Important*20 + Moderate*5 + Low") then you get this list:
Enterprise Linux 3 top 10 packages with the most 'more severe' issues:
Repeating this same process for Enterprise Linux 4, Firefox replaces Mozilla in the #1 position, thunderbird, HelixPlayer, and evolution (all new packages for Enterprise Linux 4) make the top 10 displacing libpng, cups, php, cvs.
Out of all those Red Hat Enterprise Linux vulnerablities, only 2 were critical based on the Microsoft severity scale. That means only 2 vulnerabilities could have potentially allowed a worm to spread without interaction. Out of the Microsoft vulnerabilities there are 8 critical.
So whilst it might be harder to hold 200 sweets in your hand without dropping a few, I'd rather be holding 200 sweets and 2 ticking timebombs than 30 sweets and 8 ticking timebombs.
The perl script used to analyse the raw stats has also had some updates and no longer needs to be edited to filter the vulnerabilities you are interested in. Run "perl daysofrisk.pl --help" for details.
For Red Hat Enterprise Linux 3 across all dates (20 months) we've had 13 critical vulnerabilities; of which 84% had updates available via Red Hat Network within a day of the vulnerability being public.
Despite the report's claim to incorporate a qualitative assessment of vendor reactions to serious vulnerabilities, the headline metrics treats all vulnerabilities as equal, regardless of their risk to users.
Their headline figure is 61 days of risk for a Red Hat Enterprise Linux 3 minimal installation with the addition of MySQL server from Red Hat Enterprise Linux Extras.
That sounds like a lot of days of risk - but if you filter their dataset by severity, using the Microsoft scale for determining the severity of each issue you find the following:
** Critical issues: 3 total issues. All fixed on the same day as first public disclosure, therefore having 0 days average risk.
** Critical plus Important: 49 total, with 34 average days of risk
Red Hat prioritise all vulnerabilities and fix first those that matter the most. We publish our raw data and metrics at https://people.redhat.com/mjc/
Days of risk statistics only tell a small part of the story: studies show consumers take some time to apply patches even after a vendor has produced a security update. At Red Hat we continue to work on ways to help people keep their machines up to date. Last year we added Exec-Shield to Red Hat Enterprise Linux 3 which included support for processor EDB (execute disable bit) and NX (no execute) technology. Earlier this year Red Hat Enterprise Linux 4 shipped with Security Enhanced Linux turned on by default. These technology innovations are designed to reduce the risk of security issues.
Just finished the security audit for FC4 candidate - For 20030101-20050605 there are a potential 861 CVE named vulnerabilities that could have affected FC4 packages. 759 (88%) of those are fixed because FC4 includes an upstream version that includes a fix, 8 (1%) are still outstanding, and 94 (11%) are fixed with a backported patch. I'll post all the details to fedora-devel-list later in the week. I'm also giving a keynote about Fedora and security response at FudCon later this month.
A CSO remarked to me a couple of weeks ago that their perception was that OpenSSL had a lot of serious security issues over the years. In fact it's really only had a couple of serious issues, and in total only 15 issues in the last 4 years. So in the style of the Apache vulnerability database I did one for OpenSSL. This is now publically available and we'll keep it up to date. The page is built from a XML database of the issues.
Red Hat was not given an opportunity to examine the "Role Comparison Report" or it's data in advance of publication and we believe there to be inaccuracies in the published "days of risk" metrics. These metrics are significantly different from our own findings based on data sets made publically available by our Security Response Team.
Despite the report's claim to incorporate a qualitative assessment of vendor reactions to serious vulnerabilities, the headline metrics treats all vulnerabilities as equal, regardless of their risk to users. The Red Hat Security Response Team publish complete data sets allowing calculations to be made taking into account the severity of each flaw. Red Hat prioritise all vulnerabilities and fix first those that matter the most.
For example out of the dataset examined by the report there were only 8 flaws in Red Hat Enterprise Linux 3 that would be classed as "critical" by either the Microsoft or Red Hat severity scales. Of those, three quarters were fixed within a day, and the average was 8 days. A critical vulnerability is one that could be exploited to allow remote compromise of a machine without interaction, for example by a worm.
With the current threat landscape it is no longer sufficient for operating system vendors to just respond to security issues. As part of our overall security strategy Red Hat is continually innovating to create new technologies that proactively help reduce the risk of unpatched or as yet undiscovered vulnerabilities.
In January 1995 I found a security flaw affecting the NCSA web server and I'd forwarded my patch on to Brian Behlendorf. The flaw affected the Wired.com site he was the administrator of. He told me about the Apache project and and I was invited to join the group and share the numerous patches I'd made to NCSA httpd, so my first post was back in April 1995. I can't believe that was ten years ago!
Anyway in my official Red Hat blog I've been posting stuff about the recent comparisons of security issues in Microsoft and Red Hat, and we've published a ton of useful data. See Counting Teapots and Real Data.