mark :: blog :: red hat
The metrics from the security response team have had their monthly
update at http://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.
I've been generating some more useful Fedora stats over the last few days, but I'm going to save them until FudCon next week so I've something new to talk about. I've also been adding some bookmarks to my phone so I can grab a few webcam geocaches in Karlsuhe and Frankfurt. Meanwhile the rest of the security team has been busy pushing out a lot of older 'moderate' and 'low' rated serverities whilst there isn't many 'important' rated issues in the queue.
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.
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.
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.
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.
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 ;)
|
