Mark J Cox

mark :: blog :: security

10 Nov 2005: Responsibility

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.

07 Nov 2005: Linux Worms

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!

26 Oct 2005: 80/20 rule

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.

18 Oct 2005: Free candy

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.

11 Sep 2005: Mozilla and Firefox

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

11 Sep 2005: ATA Security

Most laptops have the ability to set a hard drive password that gets asked for on boot -- take the hard drive out of the laptop and put it into another machine and you'll find you still need the password, the drive is locked by its firmware. This feature doesn't provide amazingly high security, it's known that some data recovery firms can bypass the password on some drives, some of the time, but it's probably good enough to thwart a thief who is after your machine and not your data. Anyway, most 3.5" drives found in desktop machines also have this feature, but it's mostly unsupported by motherboards (at least the sample of machines I could find). However Arne Fitzenreiter has come up with a novel solution, writing code for a BIOS that can unlock or lock desktop drives at boot. Incredibly useful also if your laptop has died, you had a password set, and you want to use the laptop drive in a desktop for a bit... guess who this applied to ;-)

In theory you should be able to program an EPROM or EEPROM, and just pop it into any old network card you have laying around that has a boot PROM socket. There is even a utility for the 3c905b/c that lets you program a EEPROM from Linux, and you can pick up a 3c905b card on ebay for under $5 including postage, so cheaper than a dedicated programmer. However the 3c905b isn't a great card to try to use the EEPROM in after it's programmed: a flaw in that card stops all the ROM contents being mapped properly.

Armed with a 3c905b for programming, an Atmel AT29C010A from Farnell Electronics, and a old 3c900 I'm glad I didn't throw away for the destination, a spare Windows PC, a couple of spare hours got it all working. Here are the final steps to make it all work for me:

Boot Linux with the 3c900 card to find it's vendor and product id (for my card it was 0x10b7, 0x9004)
Use the ATASX program in DOS to create an image for that product id
The ROM image produces won't work as it is on a 3c900, you need to fill it out to 65536 bytes just appending 0xff characters (a line of perl will sort this out)
Using the AT29C010A in the 3c905b card, use the bromutil utility (in contrib directory of etherboot) to erase the eeprom and burn the image
With the ROM and 3c900 boot to MSDOS and use the 3c90xcfg.exe program to make sure that the ROM is enabled
Reboot. Watch nothing happen (you got the vendor/product id wrong or the ROM isn't enabled) or a checksum error (the ROM image was bad, try again or use the disrom.pl script to look at the image file) or you see the ATASX program come to life.

19 Aug 2005: August Metrics Update

The metrics from the security response team have had their monthly update at http://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.

15 Jun 2005: 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.

07 Jun 2005: More Days of Risk

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

06 Jun 2005: Audit

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.

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

pics from my twitter: