Just finished the security audit for FC5 - For 20030101-20060320 there are a potential 1361 CVE named vulnerabilities that could have affected FC5 packages. 90% of those are fixed because FC5 includes an upstream version that includes a fix, 1% are still outstanding, and 9% are fixed with a backported patch. Many of the outstanding and backported entries are for issues still not dealt with upstream. For comparison FC4 had 88% by version, 1% outstanding, 11% backported.
What defines transparency? The ability to expose the worst with the best, to be accountable. My risk report was published today in Red Hat Magazine and reveals the state of security since the release of Red Hat Enterprise Linux 4 including metrics, key vulnerabilities, and the most common ways users were affected by security issues.
The Washington Post looked at how quickly Microsoft fix security issues rated as Critical in various years.
For 2005, Microsoft fixed 37 critical issues with an average of 46 days from the flaw being known to the public to them having a patch available.
For 2005, Red Hat (across all products) fixed 21 critical issues with an average of 1 day from the flaw being known to the public to having a patch available. (To get the list and a XML spreadsheet, grab the data set mentioned in my previous blog and run "perl daysofrisk.pl --distrib all --datestart 20050101 --dateend 20051231 --severity C").
(The blog also looks at the time between notification to the company and a patch, whilst daysofrisk.pl currently doesn't report that, the raw data is there and I just need to coax it out to see how we compare to the 133 days for Microsoft)
Some quotes of mine have been picked up by various news sources today, talking about how critical vulnerabilities matter more than meaningless issue counts. Anyway, as they say 95% of statistics are meaningless, I wanted to actually explain where the numbers in my quote came from. The quote is about calendar year 2005 and looks just at Red Hat Enterprise Linux 3 (since 4 wasn't out until part way into 2005). In total we fixed 10 critical vulnerabilities (critical by the Microsoft definition, as in the flaw could possibly be exploited remotely by some worm). Our average "days of risk" (the date between an issue being known to the public and us having an update available on Red Hat Network for customers) is under a day, and actually 90% of them were the same day.
But don't take my word for it, a people.redhat.com/mjc download the raw data files and the perl script and run it yourself, in this case
perl daysofrisk.pl --datestart 20050101 --dateend 20051231 --severity C --distrib rhel3
Different distributions, dates, and so on will give you different results, so you might like to customize it to see how well we did fixing the vulnerabilities that you cared about. (Zero days of risk doesn't always mean we knew about issues in advance either, the reported= date in the cve_dates.txt file can help you see when we got advance notice of an issue).
At FudCon I talked about the lack of any recent Linux worms, the last being a couple of years ago - but as of this weekend I've a new Linux worm to talk about, Lupii. This Linux worm was detected around the 5th November 2005 and is designed to exploit a flaw CVE-2005-1921 in the PHP PEAR XML-RPC Server package through a number of third party PHP scripts.
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!
It seems like we have to produce a security advisory for ethereal every month. Whilst the issues being fixed are not particularly severe (mostly "moderate" by our severity rating), I was really curious if certain packages got significantly more issues than others. We keep lots of statistics about the security issues we fix in Red Hat Enterprise Linux and most of the raw data is available publically and kept up to date. With a small addition to log packages, the following statistics were easy to produce. I examined Red Hat Enterprise Linux 3 from release to date as it has good quality vulnerability data and has been around for enough time.
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:
#1 mozilla
#2 kernel
#3 gaim
#4 krb5
#5 cvs
#6 squid
#7 ethereal
#8 libpng
#9 cups
#10 php
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.
Mike Nash of Microsoft has repeated his Red Hot demonstration where he compares the number of Windows Server 2003 vulnerabilities to those in Red Hat Enterprise Linux 3. Windows has 30ish and Red Hat has 200ish. I'd normally ignore such terrible manipulations; it's the things that Mike doesn't say that are more important. For example Red Hat Enterprise Linux contains several office suites, money management tools, several PDF viewers, various instant messaging tools all of which don't get counted in the Windows Server 2003 stats. But anyone who has ever used a Linux distribution knows that, so let's ignore the obvious flaws and look at what issues matter the most.
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 metrics from the security response team have had their monthly update at https://people.redhat.com/mjc/. This month we've also tidied up some of the XSLT used to create the web pages, so the sample reports now have the default style and contain descriptions of each vulnerability as listed at CVE.
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.
Back in March I wrote about a Role Comparison Report from Security Innovation which was published without involving Red Hat. Since that report they contacted and supplied their dataset in which we were able to correct some mistakes. This week Security Innovation released another report from the data, this time looking at the role of a Database Server.
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.
Fedora Security
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.
OpenSSL Security
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.
