A while ago I switched my personal site to use Blosxom to statically render all the pages, and last night I finished moving my weblog to it. The big advantage is I get separate RSS feeds for each part of my diary, so the Red Hat folks can take a feed of my security stories without getting all my Home Automation stuff mixed in.

So this is my last post into Advogato, get the new complete feed of my blog here.

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).

We have another new opening for an engineer working in the Security Response Team at Red Hat, to be based in Brisbane Australia. If you like tracking, investigating, triaging, debugging, and writing about security vulnerabilities, and can deal with multiple interrupts and task switching, you'd be perfect for this fast-paced job. Interested? You can find out more and apply online

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.