mark :: blog
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.
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:
For Enterprise Linux 3 they counted 34 issues up until Feb 9th:
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
What happens if you combine an old 32Mb USB key with a Geocaching travel bug dogtag and 50g of epoxy? A
USBUG emerges. I thought that rather than the usual selection of TY toys or computer parts attached to travelbug tags I'd actually build a memory travel bug, fill it with mp3's, and see if it gets any interest. (Yes, legal mp3s)
Having spare potting compound is very dangerous however. When all you have is potting compound, everything looks like it needs to be covered in epoxy ;) Anyway let's see if Tesco can still read my clubcard.
We didn't think much about lighting when our house was being built, so
it ended up being fitted out by the builder just like every other new
home with standard white plate light switches. The lights themselves
however were all the recessed R50 spotlight types. We went through
a variety of different ideas for lighting control before settling on
using "Intelliswitch" switches for the majority of the house.
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.
X10 devices are commonly used to control things like lighting and
lamps because they don't require any rewriting. You can simply use
plug adaptors or light switch replacements and the devices communicate
over the power lines. So our first experiment was using X10 for
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.
Just dim it
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
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.
Back to where we started
I don't know how we found it, but the touch switches we had installed
in the ensuite bathrooms were made by a company called "Touch'n'glo"
in the UK. Hunting around google we found a web site for them, selling
a range of "Intelliswitch" dimmers. The basic dimmer allowed you to
touch the light switch to turn the light on and off and hold it down to
dim. They were available in some lovely brushed metal finishes,
had switchable colour covers to blend into the decor of the rooms, were
not too expensive, and just looked perfect.
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.
stainless steel dimmers
Mini review: Intelliswitch 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.
Intelliswitch in the office
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'm standing in the middle of Target when my phone vibrates to tell me there is an incoming SMS message, the message is from my home automation system and tells me that the alarm has been triggered. Then a second text to show it's a confirmed alarm. There's really not much I can do about it being a few thousand miles from home apart from try calling my partner or the neighbours. If I was in the UK I'd be able to bring up a little picture from the house cameras to see what was going on, but GPRS wasn't enabled for whatever roaming partner we have in New Hampshire. Anyway it turns out my partner had triggered it without noticing and she had left the house. The mobile conversation went along the lines of "oops - how do you cancel this thing?" "Sorry, Can't hear you, all the sirens in the background" "What?" "Hello?" "helloooo?" Anyway I'd forgotten that even after turning it off you had to reset the alarm to clear the events, and until then the HA system continued to shreak, wail, and flash the lights, probably to the delight of everyone in the chocolate isle of Target.
Mapopolis is working really well once you get used to it, it's managed to get me out of a number of sticky situations and it doesn't endlessly complain like TomTom if I decide to take an alternative route, it just makes a happy "ching" sound and gets on with rerouting you.
Out in the USA for a week and I'm making myself at home. I'm watching "America's Funniest Home Videos" (which kind of makes me wonder how you could possibly find less funny videos). I'm drinking $1.25 bottled tap water. Really, this stuff actually says on it that it's taken from the public water supply. But I went and bought loads of Haloween Candy from Target, and the hotel has free wireless internet access, so it's not all that bad ;)
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.
I recently picked up a USB "charge anywhere" kit for the iPAQ; it's got a mains adapter with multiple plugs for UK/US/etc with a single little USB socket, and a USB charger lead. It also came with a car ligher adapter which gives a nice regulated 5v to a USB socket. I've already got a USB charger lead for my phone, and I just built one for my bluetooth GPS and it really cuts down on the number of chargers and leads to lug around when travelling. I wonder how long it will be before cars come with little USB sockets to charge and power goodies instead of ligher sockets? Of course all these gadgets violate the USB spec which says that you should only get 100mA unless you've negotiated with the hub for more (500mA). I guess adding the components to regulate and switch power to USB sockets isn't worth the expense or space to most designers, so all those USB lights and fans will probably keep working.
TomTom Navigator vs Mapopolis
I've been using TomTom Navigator 3 with a bluetooth GPS receiver around Scotland and it's been doing a pretty impressive job. Except it once wanted to take me off a motorway by using the private service exits for a service station. And today it sent us the wrong way up a wrong way street. Travelling to the US next week but couldn't get the TomTom add-on maps in the UK, so I ended up buying Mapopolis for about $99 that I could download online, and as well as the US maps downloaded Scotland too for comparison. Mapopolis isn't as polished a product as TomTom by far but it's technically more superiour - it knows the names of the roads and attempts to speak them
TomTom: After 300 yards turn right
Mapopolis: In 300 yards turn right into Cathedral Street. Cathedral Street is next on your right
If you want to drive and not look down, Mapopolis wins as it tells you exit numbers, road names, and so on. But for clarity TomTom wins as they supply really high quality audio for the small selection of possible words; Mapopolis has a primitive speech engine. Anyway I'm going to be driving in Boston with Mapopolis so it'll be interesting to see how it deals with all the buildings and new road layouts. I suspect i'll get used to it telling me to "turn around when possible".
I'm fed up of keep missing the postman when he rings the doorbell and we don't hear it as we're in the kitchen or have the music on. It's one of those HA things I've never got around to - in my first student house 10 years ago the first thing we did was to hook the doorbell up to our shared-house Novell server (called Malawi since it lived inside a wood box with that label) so that it popped up on everyones computer when someone was at the door (and being students we'd just all just sit there and ignore it, perhaps sending popup messages to each other to find someone who would go answer it).
I use one of these RF doorbells (Friedland Libra) and picked up a identical spare unit from Ebay for 8 pounds. I made sure to get a battery one not one that plugs directly into the mains as they don't bother using a transformer to step down the voltage, so interfacing to it is more risky.
Inside is a RF circuit and a PIC microprocessor and, fortunately, one of the output pins acts as a mute for the sound circuit. So one pin is high around 3v and is pulled low for a couple of seconds as the doorbell rings). I hooked this to a 3-pin DS2406, a one-wire device from Maxim that can monitor a single IO pin (a high is 2.2v or greater) and report on the status (and if there have been any transitions since you last spoke to it). These things are mad, a tiny package the size of a transistor with internal processor, 1Kb of EEPROM and an unique id. Pretty reliable too, one has been monitoring the heating system for the last couple of years. So one device, four wires, and now a Jabber bot announces within about a second when there is someone at the door. All for about 10 pounds of parts and an hours work.
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:
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
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:
red hat summit,