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.
When thinking about home automation most people assume that this includes having all your lighting under direct control of some computer system. You can then control everything from a central point, do cunning scene lighting, and magically turn on and off lights during the day. Since our house was already wired up and we didn't fancy rewiring to install any of the number of lighting solutions available this left us with a difficult problem.
LW10 UK light switch
The switch most commonly used for this is the LW10 which can turn lights on and off, dim them, and be controlled by the X10 protocol from other things. We didn't much like the look of the LW10; it's chunky, sticks out of the wall, and according to folks on various X10 forums constantly blows fuses. Perhaps the biggest problem with the LW10 is that you can't remotely tell it to go to a discrete dim level. You can't say "Dim to 50% brightness", only "Dim by X steps". Since we wanted to do scene lighting this was far from ideal. Also in the UK these things are quite expensive; you don't get much change out of UKP30 per unit.
On the continent the X10 light switches are much better, having the ability to dim to a discrete level and looking a lot more classy. They do need to have a neutral wire at each switch socket to function though, which is not common in the UK. Fortunately when our house was built the electricial wired a neutral to every socket. We think this was to save having to use connectors inside the ceiling as spotlights were being used, but we'll probably never know for sure. Anyway this was good news for us:
LW11 German light switch
So we bought one from Laser and put it in the living room, controlling 10 25W R50 spotlight bulbs. We can't fault the function of this switch, it works reliably and we can set the level remotely, or using a remote control with a IR X10 receiver in the same room. However these things are designed to be fitted to continental backboxes and it never really looked in place. See a picture of the lw11 in the living room. We couldn't put the right switch rocker in because the switch is slightly twisted and it just constantly catches on the edges stopping it from working reliably. Also these switches are a bit more expensive than the UK LW10.
Another problem we had in the house was over-voltage which dramatically cut the life of the expensive spotlight bulbs. Actually the only place where the life of the bulbs was not affected was in the en-suite bathrooms which we had fitted with touch switches we'd bought from somewhere like Argos. These touch switches were white, had a LED in the centre, and allowed you to turn lights on and off (and critically for the ensuite allowed the lights to turn themselves off after some number of minutes). These switches also had a soft start which we figured was mostly responsible for the increased lamp life.
Touch switches in the ensuites
So we decided that dimmers were the solution for rooms where we didn't need automatic control of lighting. The big blocky white switches from Argos were not really approriate for the look of the house. We looked around and found some amazingly nice looking dimmers that also were able to be controlled by infrared. We bought a few of these from TLC and installed them in the kitchen and bedrooms.
Cute IR touchswitches
Unfortunately it wasn't long before the first switch stopped working with a burning smell from inside it. A month or so later the second switch stopped working in an identical way. We gave up and sent the switches back, perhaps they didn't like the high voltage in the house, they certainly were not overloaded.
So by now we'd figured out that we didn't really need to be able to control every light in the house and in fact just the main living room lights made sense to control and dim for watching movies and so on. We also figured out that we really needed to use dimmers with a soft-start function to help prolong the life of the bulbs.
We chatted to their sales director and found out that the switches were designed and built in the UK and that they would soon also be available with slaves (for two or three way lighting like on our landings) and as multiple gang switches where you want to control more than one light from the same place. Perfect! We promised to write up a review of the switches and ordered about 10 of them with a slimline brushed stainless steel plate.
Brushed slimline stainless steel dimmers
The web site does a good job of explaining how these work and it's really as simple as it looks - replacing all ten of the light switches took only an hour or two and it took us longer to decide what colour inserts to use in each switch I think. The only difficulty during installation is making sure that you have the load and supply leads correct - the way our switches had been installed it was impossible to tell from inspection and we had to rely on a voltage meter (and careful fingers!).
We've been using them now for around nine months without a single incident, including dimming of some mains halogen GU10 fittings. The switches just work, look great, and visitors always admire them. Some of the switches have a slight humming noise when they are on which you can hear when very close to the switches, but that is something you'd find with any dimmer working in the same way.
So what are the downsides? to me the only real downside is that they're not computer or even infrared controllable. The geek in me wants to be able to control them remotely. If these things were X10 compatible those horrible white expensive X10 switches would be left on the shelves forever. You can now get RF switches that don't require rewiring that give you computer control, but they can cost five to ten times the price, per switch, so it's not very economical. These intelliswitches are around the same price as you'd buy a standard metal wall switch from some large DIY chain.
Okay, there is one more downside that I wasn't expecting. I was waiting for the Intelliswitch folks to release their 2-gang and slave versions of the switch so I could finish converting all the switches in the house. At the moment you walk in and see a hallway with two nice brushed stainless steel switches, and one horrible white place hall light switch. About half the switches in the house need the 2-gang or slave versions. Originally I was expecting these to be available in Spring 2004, but we're not into October and they are not available. Intelliswitch didn't reply to my mails, or phone calls with expected dates, and their web site has been broken now for a number of months. Companies house still shows Touch'n'glo as as existing. I do hope the company underneath is okay, these switches simply rock.
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.
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.
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.
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).
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.
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.
I'm sure at the end of the Linux user group meeting yesterday a guy walked off with a couple of dozen of the world tour t-shirts we were giving away; wonder if they'll turn up on ebay.
My attempt to photo blog the event with my phone camera failed as I ended up sending all the pictures to the wrong email address. D'oh.
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?