mark :: blog

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


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:

http://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?


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.


I wrote a Windows application last night! Then realised that I'd actually not written any windows stuff for over ten years. The last Windows app I wrote was with Paul Sutton back in 1993 when the Windows Sockets Library had just been brought out. We wrote a winsock Connect-4-type game. When I visited Microsoft whilst working at C2Net I actually met one of the winsock original authors who even remembered using our game. Anyway, Windows applications seem to be a whole different world; with hundreds of web sites trying to sell you utilities. Awful utilities. Things you could do with 3 lines of Perl that the author has made shareware and wants you to pay $15 to unlock.

So to spread some good Karma my OTP OPIE S/KEY client thingy is free, with source. Although I have to admit that it's probably about 40 lines of code linking to existing libraries, and it probably took me longer to write the web page and draw the icon than write the app.

Now I can get back to doing the work on the system that I needed to use the OTP calculator to log into in the first place ;)


I've just realised that I never finish anything that I do in my spare time. I tend to keep getting distracted by new and exciting projects so everything sits about 80% complete:

Spare time over the last few weeks has been a bit limited what with the OpenSSH and Sendmail issues, and I guess I need to finish off my talk for ApacheCon.

<< prev [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 ] 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.