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:
111 (33%) vendor-sec
76 (23%) relationship with upstream project (Apache, Mozilla etc)
46 (14%) public security/kernel mailing list
38 (11%) public daily list of new CVE candidates from Mitre
24 (7%) found by Red Hat internally
18 (5%) an individual (issuetracker, bugzilla, secalert mailing)
15 (4%) from another Linux vendors bugzilla (debian, gentoo etc)
7 (2%) from a security research firm
1 (1%) from a co-ordination centre like CERT/CC or NISCC
(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)
Last year I wrote about
how both Red Hat and Microsoft shipped the third party Flash browser plugin with their OS and whilst we made it easy for users who were vulnerable to get new versions, Microsoft made it hard.
With another critical security issue in Flash last week, George Ou has noticed the same thing
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.
On Monday a vulnerability was announced affecting the Linux kernel that could allow a remote attacker who can send a carefully crafted IP packet to cause a denial of service (machine crash). This issue was discovered by Dave Jones
and allocated CVE CVE-2006-0454
. As Dave notes it's so far proved difficult to reliably trigger (my attempts so far succeed in logging dst badness messages and messing up future ICMP packet receipts, but haven't triggered a crash).
This vulnerability was introduced into the Linux kernel in version 2.6.12 and therefore does not affect users of Red Hat Enterprise Linux 2.1, 3, or 4. An update for Fedora Core 4 was released yesterday.
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).
Last weekend a number of security issues (heap buffer overflows) were found in the Macromedia flash plugin, first reported as affecting Windows only. However we were able to verify yesterday that the issues do affect Linux too.
Red Hat shipped the vulnerable flash plugin in an Extras channel (not part of the main distribution, used for such third-party software) for users of Enterprise Linux 3 and 4. Microsoft shipped the vulnerable flash plugin as part of Windows XP SP1 and SP2 (according to their blog.)
Red Hat Enterprise Linux customers who installed flash just use up2date or the Red Hat Network interface in the usual way and will get their flash update along with a email notification if they need it. Or with automatic updates they'd have it by now.
Microsoft customers are on their own. Maybe they read the MSRC blog or realise that they have Flash installed and go to the Macromedia site to get their update. Meanwhile being vulnerable to an issue where a malicious web site could run arbitrary code on their system.
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.
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:
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.