|
|
tags:
all,
apache,
apachecon,
apacheweek,
bryce,
cve,
fedora,
fudcon,
geocaching,
gps,
ha,
jabber,
metrics,
microsoft,
nashville,
north carolina,
oscon,
red hat summit,
security,
trips
|
|
|
mark :: blog :: microsoft
Remember all
those
reports which compared the number of security vulnerabilities in Microsoft products against Red Hat? Well researchers
have just uncovered proof and an admission that Microsoft silently fix security issues; in one case an advisories states it fixes a single vulnerablity but it actually fixes seven.
Whilst you could perhaps argue that users don't really care if an advisory fixes one critical issue or ten (the fact it contains "at least one" is enough to force them to upgrade), all this time the Microsoft PR engine has been churning out disingenuous articles and doing demonstrations based on vulnerability count comparisons.
Last year I wrote about how both Red Hat and Microsoft shipped the third party Flash browser plugin with their OS and whilst we made it easy for users who were vulnerable to get new versions, Microsoft made it hard.
With another critical security issue in Flash last week, George Ou has noticed the same thing.
The Washington Post looked at how quickly Microsoft fix security issues rated as Critical in various years.
For 2005, Microsoft fixed 37 critical issues with an average of 46 days from the flaw being known to the public to them having a patch available.
For 2005, Red Hat (across all products) fixed 21 critical issues with an average of 1 day from the flaw being known to the public to having a patch available. (To get the list and a XML spreadsheet, grab the data set mentioned in my previous blog and run "perl daysofrisk.pl --distrib all --datestart 20050101 --dateend 20051231 --severity C").
(The blog also looks at the time between notification to the company and a patch, whilst daysofrisk.pl currently doesn't report that, the raw data is there and I just need to coax it out to see how we compare to the 133 days for Microsoft)
Last weekend a number of security issues (heap buffer overflows) were found in the Macromedia flash plugin, first reported as affecting Windows only. However we were able to verify yesterday that the issues do affect Linux too.
Red Hat shipped the vulnerable flash plugin in an Extras channel (not part of the main distribution, used for such third-party software) for users of Enterprise Linux 3 and 4. Microsoft shipped the vulnerable flash plugin as part of Windows XP SP1 and SP2 (according to their blog.)
-
Red Hat Enterprise Linux customers who installed flash just use up2date or the Red Hat Network interface in the usual way and will get their flash update along with a email notification if they need it. Or with automatic updates they'd have it by now.
-
Microsoft customers are on their own. Maybe they read the MSRC blog or realise that they have Flash installed and go to the Macromedia site to get their update. Meanwhile being vulnerable to an issue where a malicious web site could run arbitrary code on their system.
One of the top reasons that machines fall foul to security exploits is when they are not kept up to date with security issues. So it follows that to protect users a vendor needs to make security updates as easy and painless as possible. At conferences I highlight that one of the important things a Linux distribution gives you are updates across your entire stack - you don't need to use one system to grab your OS updates, another to get updates to your office application, the built-in update system in your Money tool, a manual update for Flash, and so on.
Mike Nash of Microsoft has repeated his Red Hot demonstration where he compares the number of Windows Server 2003 vulnerabilities to those in Red Hat Enterprise Linux 3. Windows has 30ish and Red Hat has 200ish. I'd normally ignore such terrible manipulations; it's the things that Mike doesn't say that are more important. For example Red Hat Enterprise Linux contains several office suites, money management tools, several PDF viewers, various instant messaging tools all of which don't get counted in the Windows Server 2003 stats. But anyone who has ever used a Linux distribution knows that, so let's ignore the obvious flaws and look at what issues matter the most.
Out of all those Red Hat Enterprise Linux vulnerablities, only 2 were critical based on the Microsoft severity scale. That means only 2 vulnerabilities could have potentially allowed a worm to spread without interaction. Out of the Microsoft vulnerabilities there are 8 critical.
So whilst it might be harder to hold 200 sweets in your hand without dropping a few, I'd rather be holding 200 sweets and 2 ticking timebombs than 30 sweets and 8 ticking timebombs.
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 http://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.
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
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.
During my short part of the world tour I got asked why I didn't keep my blog up to date with interesting stuff about what I do. The problem working on security vulnerabilities is many of them are embargoed; I spent many hours working on the recent OpenSSL issues, many days working on the Forrester Study, and all these things I couldn't talk about. Then when the embargo gets lifted I've moved onto something new and it doesn't seem worth dredging up the past.
So in the last month: I've learnt that sending the press a written statement usually gets you a better and more accurate quote than talking to them. It's probably the British accent that throws them. I've learnt that no matter how hard you try you can't find everyone who uses OpenSSL in their product to tell them in advance about security issues, and the ones you miss end up being annoyed. I've learnt that the latest attempt to cure my migraines has a side effect in that I don't get nervous before giving presentations (it felt like I was watching myself from above). I've learnt that April fools jokes on the web are not funny (well apart from the "Klingon Eye for the Human Guy" one and our Apache PDA one from a few years ago).
Just a month before the end of life of Red Hat Linux 9 I finally got around to upgrading some old Red Hat 7.1 machines to run Advanced Server 2.1AS; only one reboot and about 20 minutes of my time required. I was so pleased with myself I spent an hour sending in one of my patches for
ZoneMinder which is used to record and upload cctv stuff that goes on outside my house.
I'm sitting at the very back of a packed hall, typing this
live as Craig Mundie from Microsoft talks about his thoughts
on open source. He started by saying that Microsoft's
problems and comments are around the free software movement
rather than the open source movement. "Open source isn't
the issue".
It must be strange for him up on stage looking out over a
sea of people wearing plastic red hats. Yes, it's a bit of
a publicity stunt, but we must have got about a third of all
the attendees wearing the fedoras. I had great fun handing
them out on the way in, getting trampled in the rush, but
the attitude of everyone was great. Apart from the guy who
worked for SuSe who didn't want one. Not even to burn,
apparantly.
|
|
