mark :: blog

<< prev [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 ] next >>

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 --distrib all --datestart 20050101 --dateend 20051231 --severity C").

(The blog also looks at the time between notification to the company and a patch, whilst 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 download the raw data files and the perl script and run it yourself, in this case

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

Earlier this year I finally got around to buying a replacement TV, and settled on a Hitachi PD7200 plasma. First thing I noticed was a port on the back labelled 'service use only' which sounded like a fun challenge.

service use only

Turns out that on the Hitachi PD7200 plasma this is a serial port that is enabled by default, so you just need to know the right protocol and you can talk to the plasma. I don't have a PC close to the plasma, but last year I did buy some Lantronix MSS100 devices which have a 10/100 ethernet connection at one end, and a serial RS232 port at the other. I was't quite sure what I'd use them for, but for under 50 pounds each they seemed like a bargain at the time.

serial to parallel converter

Hitachi technical support replied to my query within hours and sent me a couple of PDF documents outlining the protocol, so this was going to be much easier than guesswork.

Knowing the filename, google found this online version, Hitachi control protocol, pdf

A small amount of perl later, and I had script that could query the TV to find out various things (settings, channel, and interestingly the number of hours the TV has been on since it started life). The script can also get the TV to do various things like turn itself on and off and select channels.

Download Hitachi Plasma control (perl, 2k)

So now I have to think of a use for this. I guess I could get the TV to change channels when some event occurs (like one of the motion sensors triggering) or perhaps daily grab the TV panel lifetime to see how many hours of TV we watch a day (and perhaps what channels). Perhaps I could automatically dim the lights and select cinema mode if the channel is changed to DVD (although I could do that just using a programmable remote). I'm sure I'll think of a use for this eventually, but it was a fun diversion for a cold and wet Scottish weekend.

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

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!

I've had my Nokia 770 for a little over a week. On Monday evening I managed to pry it out of my girlfriends hands for long enough to try running one of the first old GDK C apps that I wrote. Although the app worked fine in the development environment it failed on the device itself due to assumptions about having 24 bit colour depth.

A simple source code change from using gdk_pixbuf_render_pixmap_and_mask(a,b,c,d) to gdk_pixbuf_render_pixmap_and_mask_for_colormap(a,gtk_colormap_get_system(),b,c,d) solved it.

The unit is very cute and got a lot of attention when I showed it off last weekend; but there are a few niggles - the biggest is a lack of a docking station. It's also far worse at picking up the weak wireless signal in the house than the Orinoco pcmcia cards.

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.

On Friday we read about the Firefox security issue, CAN-2005-2871. This issue looked like it could well be a 'critical' issue potentially allowing a malicious web page to control a heap buffer overflow. We know that various technologies in Red Hat Enterprise Linux and Fedora Core are likely to reduce the chances of this being actually exploitable by an attacker -- checks foil the most usual way of exploiting heap overflows by messing with malloc control structures, and on x86 at least heap randomization makes an exploit harder. But this issue was already public and so we didn't have the luxury of time to be able to test the mitigation. So we initiated our emergency response process to get the packages through development and QA and got Firefox and Mozilla packages out via Red Hat Network within 20 hours of this issue being public (due to the awesome work from engineering folks, QA folks, and the security response team who worked late into Friday night to get this done).

<< prev [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 ] next >>

Hi! I'm Mark Cox. This blog gives my thoughts and opinions on my security work, open source, fedora, home automation, and other topics.