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.
What a busy day; doing the OpenSSL release manager role for the recent security updates, testing packages, dealing with the third parties, being a third party, rolling, pushing, correcting.
What is disturbing is a report from a third party company who is vulnerable to one of the Denial of service issues that said that it wasn't a security issue as their were hundreds of other possible DoS attacks. Actually, this attack causes OpenSSL to crash. We've got a proof of concept, you don't have to send more than a kb of data to get OpenSSL to crash remotely. This can be quite serious if you have a service that can't recover from that. Things like Apache (when running in its default prefork memory model) can recover quite well - they just spawn off a new child to replace the dead one. This is going to use up some extra resources, but depending on the platform it's quite minor (and will stop as soon as the attacker stops sending malicious packets). Not everything that listens to the network that uses OpenSSL is so resiliant.
Going to be in London next weekend?
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.
Had an interesting week wading through vulnerability details and the various advisories which never really seem to match the facts. Take one Linux vendor for example who got confused about the Oracle mod_dav vulnerability and, even though they were not affected by the vulnerability, released new Apache mod_dav packages. To add to the confusion their newly released errata packages had actually added a patch which added in the vulnerability. So they started out not vulnerable, but then released a patch which was meant to remove the vulnerability but actually really made them vulnerable. No wonder folks are confused. Wrote a bit of a rant about it in Apache Week this week.
What a busy couple of days. It all started last month with a seemingly innocent DOS being reported to the Apache security team. jorton and I spent some time analysing it and found that although it wasn't exploitable on 32 bit until platforms it may well be exploitable on some 64 bit machines. Then started the co- ordination work with CERT.
Then, suddenly, the ISS team announced the same issue publically causing us to go into firefighting mode and release the advisory (which I'd fortunately already drafted and got positive feedback on), followed by seemingly hundreds of press calls, lots of additional analysis, and reading ISS say I was untrustworthy in some Chicago newspaper ;-)
Now for some sleep
