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 secalert@redhat.com an email). We also have other mappings which are automatically generated from our errata system which we'll publish soon.
It's been an interesting month so far with several reports of people comparing the number of vulnerabilities in Microsoft software to those in Linux distributions. I've previously talked at length about these types of studies after last years Forrester report, but it seems that these comparisons don't get any better.
Microsoft are quoted and say that in 2005 to Feb 9th that Windows Server 2003 had 15 vulnerabilities, but in the same period Red Hat Enterprise Linux 3 had 34, more than double!
What they failed to mention was that of those vulnerabilities, 3 of the flaws affecting Windows Server 2003 were classed by Microsoft as "Critical", flaws that can be remotely exploited without user interaction to take control of a machine, for example by a worm. Of the Enterprise Linux 3 vulnerabilities quoted, using the Microsoft scale, none were Critical. Metrics like those they quoted are completely worthless if you do not take into account the risk that the vulnerabilities actually pose to users. One Critical vulnerability and a worm or remote attacker owns your machine.
So of those 15 Microsoft issues:
3 Critical
3 Important
8 Moderate
1 Low
For Enterprise Linux 3 they counted 34 issues up until Feb 9th:
0 Critical
12 Important
14 Moderate
8 Low
I'm not saying that Red Hat is immune to Critical vulnerabilities, in fact in the lifetime of Enterprise Linux 3 (Nov 2003 to date) we've had 12. I'm also not saying that I think these stats show that Linux is more secure (or safer) than Windows, just they just show how useless stats like these are.
One of the things we at Red Hat can do to help our users determine the risk of security issues is to provide some guidance on which issues Red Hat is the most worried about. Since the release of Red Hat Enterprise Linux 4 last week, the Red Hat Security Response Team has been including severity impact statements on all security advisories. find out more. We've also gone back and applied the classification to every Enterprise Linux advisory we've produced, and will publish that list shortly.
In the Red Hat earnings call last night, 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. See some news about the report.
Red Hat Enterprise Linux 3 was released in November 2003 and I wanted to find out what it's survival rate on x86 would likely be to compare to Windows. We'll first look at the worst case and find what flaws have been fixed in RHEL3 that could possibly be remotely exploited. Then from that work out how often they are exploited to come up with a survivability time for RHEL3.
Firstly we need to discount flaws that require user interaction as they are not included in a survivability study - for example CAN-2004-0597 or CAN-2004-0722 where a user would have to visit a malicious web page, preview a malicious email, or open a malicious file with a particular application. So we won't include CAN-2004-0006, a flaw in Gaim that requires a user to be sent a malicious packet from a trusted buddy, for example.
From the release of RHEL3 until 19th August 2004 we have the following flaws that could be triggered remotely:
CAN-2004-0493 is a memory leak in Apache. This allowed a remote attacker to perform a denial of service attack against the server by forcing it to consume large amounts of memory. This flaw could possibly be use in combination with a flaw in PHP to execute arbitrary code. However no exploit has been seen in the wild for this issue, and it looks incredibly difficult to exploit. A second memory leak affected SSL enabled Apache, CAN-2004-0113. These wouldn't allow a full installation of RHEL3 to be remotely compromised.
Flaws in OpenSSL were found that could lead to a crash, CAN-2004-0079. Any service that accepts SSL traffic using OpenSSL to decode it could be vulnerable to this issue. However for servers like Apache, a single child crashing is automatically recovered and will not even cause a Denial of Service.
A flaw in the ISAKMP daemon in racoon could lead to a DoS, CAN-2004-0403, but this daemon is not used by default.
Using one of the above flaws, remote probes could cause a service to crash or exceed OS resource limits and be terminated. These have little impact on the survivability of a machine. What affects survivability are flaws that could lead to remote code execution or a total machine crash.
Two of these type of flaws are in CVS, CAN-2004-0396 and CAN-2004-0414. These flaws could allow a remote user who has the permission to connect to a CVS server to execute arbitrary code on the server. An exploit for these flaws is widely available. However the majority of systems would not be running a CVS server, it certainly isn't default, and in order for this to be remotely exploited by an unknown attacker a system would need to have been set up to allow remote anonymous CVS access.
A flaw in Samba SWAT, CAN-2004-0600, allows remote code execution but only where the SWAT (administration) port is open to the internet. This is not the default, and not a sensible or usual configuration.
The final issue is an overflow in rsync, CAN-2003-0962. This flaw is similar to the CVS flaw in that it requires a system to be running an open rsync server to be exploited.
So a full install of a Red Hat Enterprise Linux 3 box that was connected to the internet in November 2003 even without the firewall and without receiving updates would still remain uncompromised (and still running) to this day.
It's not to say that a RHEL3 user couldn't get compromised - but that's not the point of the survivability statistuc. In order to get compromised, a user would have to have either enabled anonymous rsync, SWAT, or be running an open CVS server, none of which are default or common. Or a user would have to take some action like visiting a malicious web site or receiving and opening a malicious email.
I've just finished a run to update Red Hat security advisories from CAN- to CVE- names, 180 advisories were updated.
In security advisories we include references to the MITE Common Vulnerabilities and Exposures dictionary for each vulnerability, you'll see us link to names like CAN-2004-0111. The CAN- prefix shows that the entry is a candidate that has been proposed for inclusion in the dictionary. From time to time the editorial board (of which Red Hat is a member) votes on the candidates and the ones that pass get promoted to full CVE- prefixes, but only the prefix changes. In the recent round of voting I accepted or modified 145 entries. Yesterday the CVE project promoted 480 CAN names to CVE names. We've updated our mappings so that if you look on the Red Hat Network or online at our advisory texts you'll see reference to the promoted names. We've not gone through and altered the text, or are we likely to, so you might still see texts refer to CAN-2004-0111 for example, but all the links are magically updated to CVE-2004-0111.
When looking at vulnerabilities that affect Linux have you ever wanted a quick way to see how Red Hat is affected? Simply take your Common Vulnerabilities and Exposures name and pop it into a URL like this:
https://rhn.redhat.com/cve/CAN-2003-0192.html
Just don't forget the .html at the end. If this is an issue that Red Hat has fixed in any of our products you'll get links to the relevant advisories.
Last week we published fixes for flaws in libPNG found by a UK researcher. Since these flaws didn't get much press attention I wanted to take this opportunity to fill in a few of the details. If you don't want the details just goto https://rhn.redhat.com/cve/CAN-2004-0597.html and update your systems right now.
Chris Evans discovered a stack buffer overflow in the libPNG library. This means that an attacker could create a malicious PNG image file to take advantage of the flaw. If you were to view that malicious image on your system then it could execute arbitrary code as you. Since most applications that display PNG files are linked to libPNG or contain libPNG code, that increases the risk of this flaw.
Whilst researching affected applications we found that most browsers were affected - so an attacker would simply have to put a malicious image onto a web site that you visit. You'd still need to be forced to visit that web site though. Or maybe the attacker can act as a man-in-the-middle and inject the malicious image file (as was reported recently at DefCon where wireless surfers had all their images replaced). More worrying are perhaps email applications that might load images by default, which could allow propegation of a worm. This isn't an issue that only affects Linux; just sending malicious images in attachments to someone using AppleMail on MAC OSX is enough to trigger the flaw.
Although i've not yet seen an exploit containing shellcode for this issue we believe it is triviallly exploitable. This is a "Critical" update.
Red Hat Enterprise Linux users need to update their libpng and Mozilla (which contained it's own copy of libpng) packages. Updating libpng is sufficient to protect all the applications that use that library to decode images (although you'll need to restart any applications you've already got running to pick up the change, it's probably easiest just to restart your system if you're unsure).
Fedora Core users should be protected against possible exploits of this issue by exec-shield, but should still upgrade (as a malicious PNG file would still crash an application).
https://rhn.redhat.com/cve/CAN-2004-0597.html
Because libpng is under a BSD-style license, anyone is basically free to use or include libpng even in closed-source products. So expect to see a whole raft of advisories over the coming weeks as other vendors come to discover that they're vulnerable to this issue.
So according to a Secunia advisory I just read there is a new flaw in Apache that allows attackers to "compromise a vulnerable system". [source]
They got that information from a Connectiva security advisory. That advisory actually says "trigger the execution of arbitrary commands" but if you read the context you'll find that in fact what it means is that a cunning attacker could use a minor flaw in Apache that allows it to log escape characters in order to exploit possible flaws in terminal emulators to execure arbitrary commands if you view the log file. [source].
So we've magically turned an issue which is of quite minor risk and minor severity into one classed as "Moderately Critical". Using the same logic you could then use publicised (but fixed) flaws in the Linux kernel to gain root privileges and we've got a remote root exploit in Apache folks! It's Chinese Whisper Security Advisories at their best.
So our joint statement in response to the Forrester Study is now available and it got to slashdot and other places. It should be an identical statement from each vendors site - although I think the European -ise's got replaced with -ize's in some of the statements. It's quite an event to have four competing Linux distributions giving a joint statement on an issue - but behind the scenes this goes on all the time. Every day we work with our competitors in the other Linux vendor security teams to make sure that Linux users get quality, peer-reviewed, security fixes in a timely fashion.
As I was commiting the template for this weeks issue of Apache Week I noticed that it has now been exactly eight years since I wrote the first issue. Back then Apache wasn't so popular and the documentation was lacking. Apache Week was designed specifically to give administrators the confidence to try the Apache web server on their machines without having to parse the hundreds of messages each week on the developer mailing list. That first issue was written over a 64k ISDN dial-up line from a computer perched on stark IKEA tabletop. Friday afternoons were spent writing up what had happened during the week. Not much has changed. Actually, I think that IKEA tabletop is still sitting in storage somewhere at Red Hat in Guildford. I wish I'd kept hold of it, it would have been useful for my girlfriends sons train layout.
Over the years there have been many times when we've thought about stopping production, usually when a competitor announced some other Apache magazine that we thought would do a better job than we do. But most of them gave up. They probably realised that there wasn't any money to be made from an Apache httpd journal.
UK Web became C2Net which became Red Hat, and Apache Week is still going strong. We'll have to think of something exciting to do for our tenth birthday.
My paper on "Security Response and Vendor Accountability for Open Source Software" was accepted for Linux World 2003 in San Francisco and I'm giving a similar talk at Linux for Business in London on the 10th June. The role of the open source vendor is often neglected when folks talk about the security of open source software.
House modifications are coming along well, with updates to the Home Automation security software (a few suprises for any intruder), and some large black marble balls on a rockery out the front. Tracy has been spending a few days pressure-washing the driveway which is fun apart from the occasional lump of sand that gets blasted at random parts of your body. Sand in your nose is quite annoying.
