Older blog entries for mjcox (starting at number 134)

I saw a couple of Fujitsu Point 1600 tablets going on ebay for US$150 for the pair and couldn't resist. My house already has a number of Fujitsu Point 510 tablets around with a simple Perl/TK interface to control heating, lighting, security, house cams, incoming phone calls and so on. But the old 510's were starting to show off their less than impressive specs 56Mb 75MHz 256 colour. The 1600 is a bit better at 160Mb and 166MHz with enough graphics ram to go to 24 bit colour at 800x600. Fortunately the 1600 is pretty similar to the 510 externally so the wall mount is the same, and in fact they use the same LCD and touchscreen so I can use the 510's as backlight spares (isn't it wacky when you can get a new 510 for about half the price of a replacement backlight for the LCD). Of course now I have faster tablets it means I'm likely to write more GUI to slow them back down again.

New Fedora Stats

I've been generating some more useful Fedora stats over the last few days, but I'm going to save them until FudCon next week so I've something new to talk about. I've also been adding some bookmarks to my phone so I can grab a few webcam geocaches in Karlsuhe and Frankfurt. Meanwhile the rest of the security team has been busy pushing out a lot of older 'moderate' and 'low' rated serverities whilst there isn't many 'important' rated issues in the queue.

Back in March I wrote about a Role Comparison Report comparing vulnerability response times in Microsoft and Red Hat Enterprise Linux from Security Innovation -- published without involving Red Hat. Since that report they contacted me 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 an awful 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. I frequently publish our raw data and metrics at http://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. So last year we added Exec-Shield to Red Hat Enterprise Linux 3 which also 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.

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.

Geocaching

Completed our 100th cache last weekend after a day out to grab some caches just north of Edinburgh. Took us a year to get to 100, but rather than try to do as many caches as possible we're trying to do a selection of interesting ones in interesting places. Since most caches in Scotland seem to involve 2 mile hikes we don't tend to do many each weekend. A cache last weekend took us within a few hundred yards of a certain blue and yellow swedish furniture store, which proved amazingly expensive with more bookcases, a new bed, shelving, and a packet of mini-daim bars needed to make the construction process less stressful.

We've not really given Apache Week any priority in the last few months -- in fact we've not posted a new issue since October 2004. So I'm glad we didn't rename it Apache Month. Time to register apachewhenthereissomethinginteresting.com.

Anyway, the most useful thing that I've kept up to date in Apache Week is the database of vulnerabilities that affects the Apache Web server v1.3 and v2.0. This list was even being linked to directly by httpd.apache.org so I made good on a promise I made a year ago and moved the database to the official site. Apache Week uses xslt for transforming the database, but the Apache site used velocity for page markup, but no one seemed to mind me adding ant-trax.jar to the site so the database gets converted from xslt to the page format that gets marked up by velocity. The end result is a couple of nice HTML pages on the official Apache site that list all the vulnerabilities that is easy for us to keep up to date.

Today a "Role Comparison Report" from Security Innovation was published which has a headline that Red Hat fix security issues less than half as fast as Microsoft.

Red Hat was not given an opportunity to examine the "Role Comparison Report" or it's data in advance of publication and I 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. I work with these stats on a daily basis and frequently publish reports based on them. I've put some sample reports, including ones for the distribution and timeline examined in the report on my Red Hat page along with the perl script we use to do the analysis so you can judge for yourself.

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.

But let's put these metrics into context - with the current threat landscape it is no longer sufficient for operating system vendors to just respond to security issues. We've had a firewall enabled by default in our products since 1999. We've digitally signed all software updates from Red Hat since 1996. 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. That's why you see things like Exec-Shield ,which proved it's ability in Fedora Core to reduce the risk of some exploits, accelerated into the Enterprise product, and why you see us work on integrating technologies such as SELinux configured and enabled by default.

Roy Fielding sent out a message reminding us all that the Apache web server just celebrated it's tenth birthday.

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.

My girlfriends computer (made up of lots of bits of my old computers) has been acting weird for some time in a way that defied logic. Swapping around the memory would cause it to crash randomly, but the memory was okay. Sometimes the machine would fail to turn itself off. Sometimes the machine wouldn't turn itself on. Sometimes it hung for no reason at all. After swapping various hardware, changing BIOS settings, and playing around for months on and off with no effect I finally gave in and bought her a new PC from DELL. We plugged it in last night and it showed almost identical symptoms, wacky. Upstairs it worked fine. In her office it didn't. Is the power downstairs (on a separate circuit) dodgy? Was it the mains leads? No. It turned out to be the fairly old CRT monitor. Use a different CRT and the machines act normally. Plug in the old CRT and they start behaving erratically. The monitor was the last thing I thought of that would have been causing these problems.

What happens if you combine an old 32Mb USB key with a Geocaching travel bug dogtag and 50g of epoxy? A USBUG emerges. I thought that rather than the usual selection of TY toys or computer parts attached to travelbug tags I'd actually build a memory travel bug, fill it with mp3's, and see if it gets any interest. (Yes, legal mp3s)

Having spare potting compound is very dangerous however. When all you have is potting compound, everything looks like it needs to be covered in epoxy ;) Anyway let's see if Tesco can still read my clubcard.

Back in the UK, and last night in the Red Hat earnings call Matthew Szulik mentioned some statistics on the survivability of Red Hat Enterprise Linux 3. In August 2004, SANS Internet Storm Center published statistics on the survival time of Windows by looking at the average time between probes/worms that could affect an unpatched system. The findings showed that it would take only 20 minutes on average for a machine to be compromised remotely, less than the time it would take to download all the updates to protect against those flaws. We tried to do the same comparison with RHEL3 but found you can't because there were no worms or exploits that a full install with default configuration could have taken advantage of without user interaction.

I'm standing in the middle of Target when my phone vibrates to tell me there is an incoming SMS message, the message is from my home automation system and tells me that the alarm has been triggered. Then a second text to show it's a confirmed alarm. There's really not much I can do about it being a few thousand miles from home apart from try calling my partner or the neighbours. If I was in the UK I'd be able to bring up a little picture from the house cameras to see what was going on, but GPRS wasn't enabled for whatever roaming partner we have in New Hampshire. Anyway it turns out my partner had triggered it without noticing and she had left the house. The mobile conversation went along the lines of "oops - how do you cancel this thing?" "Sorry, Can't hear you, all the sirens in the background" "What?" "Hello?" "helloooo?" Anyway I'd forgotten that even after turning it off you had to reset the alarm to clear the events, and until then the HA system continued to shreak, wail, and flash the lights, probably to the delight of everyone in the chocolate isle of Target.

Mapopolis is working really well once you get used to it, it's managed to get me out of a number of sticky situations and it doesn't endlessly complain like TomTom if I decide to take an alternative route, it just makes a happy "ching" sound and gets on with rerouting you.