mark :: blog

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


On Friday we read about the Firefox security issue, CAN-2005-2871. This issue looked like it could well be a 'critical' issue potentially allowing a malicious web page to control a heap buffer overflow. We know that various technologies in Red Hat Enterprise Linux and Fedora Core are likely to reduce the chances of this being actually exploitable by an attacker -- checks foil the most usual way of exploiting heap overflows by messing with malloc control structures, and on x86 at least heap randomization makes an exploit harder. But this issue was already public and so we didn't have the luxury of time to be able to test the mitigation. So we initiated our emergency response process to get the packages through development and QA and got Firefox and Mozilla packages out via Red Hat Network within 20 hours of this issue being public (due to the awesome work from engineering folks, QA folks, and the security response team who worked late into Friday night to get this done).


The metrics from the security response team have had their monthly update at https://people.redhat.com/mjc/. This month we've also tidied up some of the XSLT used to create the web pages, so the sample reports now have the default style and contain descriptions of each vulnerability as listed at CVE.

The perl script used to analyse the raw stats has also had some updates and no longer needs to be edited to filter the vulnerabilities you are interested in. Run "perl daysofrisk.pl --help" for details.

For Red Hat Enterprise Linux 3 across all dates (20 months) we've had 13 critical vulnerabilities; of which 84% had updates available via Red Hat Network within a day of the vulnerability being public.


Back in March I wrote about a Role Comparison Report from Security Innovation which was published without involving Red Hat. Since that report they contacted and supplied their dataset in which we were able to correct some mistakes. This week Security Innovation released another report from the data, this time looking at the role of a Database Server.

Despite the report's claim to incorporate a qualitative assessment of vendor reactions to serious vulnerabilities, the headline metrics treats all vulnerabilities as equal, regardless of their risk to users.

Their headline figure is 61 days of risk for a Red Hat Enterprise Linux 3 minimal installation with the addition of MySQL server from Red Hat Enterprise Linux Extras.

That sounds like a lot of days of risk - but if you filter their dataset by severity, using the Microsoft scale for determining the severity of each issue you find the following:

** Critical issues: 3 total issues. All fixed on the same day as first public disclosure, therefore having 0 days average risk.

** Critical plus Important: 49 total, with 34 average days of risk

Red Hat prioritise all vulnerabilities and fix first those that matter the most. We publish our raw data and metrics at https://people.redhat.com/mjc/

Days of risk statistics only tell a small part of the story: studies show consumers take some time to apply patches even after a vendor has produced a security update. At Red Hat we continue to work on ways to help people keep their machines up to date. Last year we added Exec-Shield to Red Hat Enterprise Linux 3 which included support for processor EDB (execute disable bit) and NX (no execute) technology. Earlier this year Red Hat Enterprise Linux 4 shipped with Security Enhanced Linux turned on by default. These technology innovations are designed to reduce the risk of security issues.


Fedora Security

Just finished the security audit for FC4 candidate - For 20030101-20050605 there are a potential 861 CVE named vulnerabilities that could have affected FC4 packages. 759 (88%) of those are fixed because FC4 includes an upstream version that includes a fix, 8 (1%) are still outstanding, and 94 (11%) are fixed with a backported patch. I'll post all the details to fedora-devel-list later in the week. I'm also giving a keynote about Fedora and security response at FudCon later this month.

OpenSSL Security

A CSO remarked to me a couple of weeks ago that their perception was that OpenSSL had a lot of serious security issues over the years. In fact it's really only had a couple of serious issues, and in total only 15 issues in the last 4 years. So in the style of the Apache vulnerability database I did one for OpenSSL. This is now publically available and we'll keep it up to date. The page is built from a XML database of the issues.


We've not really given Apache Week any priority in the last few months -- in fact we've not posted a new issue since October 2004. So I'm glad we didn't rename it Apache Month. Time to register apachewhenthereissomethinginteresting.com.

Anyway, the most useful thing that I've kept up to date in Apache Week is the database of vulnerabilities that affects the Apache Web server v1.3 and v2.0. This list was even being linked to directly by httpd.apache.org so I made good on a promise I made a year ago and moved the database to the official site. Apache Week uses xslt for transforming the database, but the Apache site used velocity for page markup, but no one seemed to mind me adding ant-trax.jar to the site so the database gets converted from xslt to the page format that gets marked up by velocity. The end result is a couple of nice HTML pages on the official Apache site that list all the vulnerabilities that is easy for us to keep up to date.


Today a "Role Comparison Report" from Security Innovation was published which has a headline that we fix security issues less than half as fast as Microsoft.

Red Hat was not given an opportunity to examine the "Role Comparison Report" or it's data in advance of publication and we believe there to be inaccuracies in the published "days of risk" metrics. These metrics are significantly different from our own findings based on data sets made publically available by our Security Response Team.

Despite the report's claim to incorporate a qualitative assessment of vendor reactions to serious vulnerabilities, the headline metrics treats all vulnerabilities as equal, regardless of their risk to users. The Red Hat Security Response Team publish complete data sets allowing calculations to be made taking into account the severity of each flaw. Red Hat prioritise all vulnerabilities and fix first those that matter the most.

For example out of the dataset examined by the report there were only 8 flaws in Red Hat Enterprise Linux 3 that would be classed as "critical" by either the Microsoft or Red Hat severity scales. Of those, three quarters were fixed within a day, and the average was 8 days. A critical vulnerability is one that could be exploited to allow remote compromise of a machine without interaction, for example by a worm.

With the current threat landscape it is no longer sufficient for operating system vendors to just respond to security issues. As part of our overall security strategy Red Hat is continually innovating to create new technologies that proactively help reduce the risk of unpatched or as yet undiscovered vulnerabilities.

Link to the report

Data set and perl script to let you run your own metrics from the Security Response Team


Roy Fielding sent out a message reminding us all that the Apache web server just celebrated it's tenth birthday.

In January 1995 I found a security flaw affecting the NCSA web server and I'd forwarded my patch on to Brian Behlendorf. The flaw affected the Wired.com site he was the administrator of. He told me about the Apache project and and I was invited to join the group and share the numerous patches I'd made to NCSA httpd, so my first post was back in April 1995. I can't believe that was ten years ago!

Anyway in my official Red Hat blog I've been posting stuff about the recent comparisons of security issues in Microsoft and Red Hat, and we've published a ton of useful data. See Counting Teapots and Real Data.


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.


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 lighting

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 lighting control.


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 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.

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.


Brushed slimline 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

<< 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.