mark :: blog :: security
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.
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.
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).
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.
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
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
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
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.
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.
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.
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 we 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 we
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
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.
With the current threat landscape it is no longer sufficient for
operating system vendors to just respond to security issues. 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.
and perl script to let you run your own metrics from the Security
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.
Yesterday I promised that we'd publish some of the mappings that we
internally use in the Security Response Team. Three of these are available now.
The first is a mapping of severity for every security advisory for
Red Hat Enterprise Linux and Stronghold from release date through to
Feb 15th 2005 (after Feb 15th 2005 this information is included on
advisories as published).
These severities assigned to each RHSA are based on a unique
assement of how each individual flaw affects the particular
distribution, then rolling up the severities and picking the worst to
give the overall severity rating. A second mapping therefore gives
the severity rating we assigned to each individual vulnerability, by
CVE name. Included in this mapping is also the date that each issue
was first known publically.
The final mapping is RHSA to release date. In the majority of
cases the "Issue Date" displayed on the advisory or by Red Hat Network
is correct, however this file also contains fixes where the issue date
was published incorrectly, was missing, or delayed. This file
contains every RHSA from 2000 to date, and will get get updated from
time to time.
We'll update the mappings from time to time (we keep up to date
copies internally, so if you have specific questions or we've
forgotten to update them in a while just drop firstname.lastname@example.org an
email). We also have other mappings which are automatically generated
from our errata system which we'll publish soon.
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: