So one of the points we make in the joint statement is that the Forrester report treats all vulnerabilities as equal. After all the time and effort we all put into the raw data set, seeing it boiled down to a simple mean average is disappointing.
Anyone who follows the security advisories for any Linux distribution knows that the critical fixes are fixed first and fixed quickly. Let's take the Microsoft definition of a "critical vulnerability" for example. Then for Red Hat Enterprise Linux in the 21 months from release to March 2004 there were 13 CVE named issues that matched the definition. 77% of those were fixed within a day of them being public. The mean was 1.1 days.
Even if we take into account attacks Microsoft would not class as critcial; things like privilege escalation, remote DoS, information leaks, etc. then we get to 47 CVE named issues where 57% were fixed within a day of them being public. The mean was 7 days.
You'll see the same effect for all the Linux distributors mentioned in the report. However not even all "critical" vulnerabilities have the same risk to all users - you might not be using fetchmail, or your box might not have an SSL-enabled webserver. So really, to get an accurate assesment of "days of risk", you need to look at which of the vulnerabilities affected you, which posed the most risk to your organisation, then see how quickly your vendor fixed them.
"Versions of Red Hat Linux since 7.1, and Red Hat Linux Advanced Server shipped with BIND 9 are are therefore not vulnerable to these issues.
Older releases (6.2, 7.0) of Red Hat Linux shipped with versions of BIND which are vulnerable to these issues, however a Red Hat security errata in July 2002 upgraded all our supported distributions to BIND 9.2.1 which is not vulnerable to these issues."
Okay so the reporter released early and therefore missed out on the full analysis.
This is CAN-2002-0840
Prevent a cross-site scripting vulnerability in the default error page. The issue could only be exploited if the directive UseCanonicalName is set to Off and a server is being run at a domain that allows wildcard DNS. (which are not that common)
The default setting has been Off in 2.0 since 2.0.33; 1.3 has always had it On, so is not vulnerable by default, but is vulnerable if you set UseCanonicalName to Off.
Affects Apache 2.0 all versions including 2.0.42 and 1.3 all versions up to 1.3.26
Expect fixes shortly, but this isn't a very critical vulnerability.
Looks like they've missed a (long) to (int) conversion that happens later which strips the high word and lets you have exact control over the memcpy length.
Although the CNet article tells you otherwise, the open source verison of Apache 2.0 is not available on Monday, and as stated in Apache Week, is only just becoming stable enough for another beta release. Covalent are launching a commercial product that is based on Apache 2.0 but with proprietary extensions (the Apache license unlike the GPL allows this). IBM's httpd server has been based on a 2.0 beta for a number of months. Since Covalent say they've made it Enterprise Ready they must have cured the performance and stability problems, when these get contributed back to the main Apache 2.0 tree everyone wins.
Yes, Actually the 1.3.22 Announcement that we sent out was exactly the same as the one I initially wrote for Apache Week. Whats the point of writing it twice?
"Camelot did not pay my fee or expenses for ApacheCon Santa Clara, way back in April, and called today Friday, July 13, at 4:00 am, to say they are closing the company.
Camelot appears to have traded while insolvent, a situation that is illegal in some countries."
Slashdot Mirror
http://blogs.redhat.com/people/archive/000201.html links you to the raw downloadable data on how well Red Hat really did and a trivial Perl script to analyse it and drop out all sorts of metrics.
So one of the points we make in the joint statement is that the Forrester report treats all vulnerabilities as equal. After all the time and effort we all put into the raw data set, seeing it boiled down to a simple mean average is disappointing.
Anyone who follows the security advisories for any Linux distribution knows that the critical fixes are fixed first and fixed quickly. Let's take the Microsoft definition of a "critical vulnerability" for example. Then for Red Hat Enterprise Linux in the 21 months from release to March 2004 there were 13 CVE named issues that matched the definition. 77% of those were fixed within a day of them being public. The mean was 1.1 days.
Even if we take into account attacks Microsoft would not class as critcial; things like privilege escalation, remote DoS, information leaks, etc. then we get to 47 CVE named issues where 57% were fixed within a day of them being public. The mean was 7 days.
You'll see the same effect for all the Linux distributors mentioned in the report. However not even all "critical" vulnerabilities have the same risk to all users - you might not be using fetchmail, or your box might not have an SSL-enabled webserver. So really, to get an accurate assesment of "days of risk", you need to look at which of the vulnerabilities affected you, which posed the most risk to your organisation, then see how quickly your vendor fixed them.
-- Mark
Official Red Hat Statement
"Versions of Red Hat Linux since 7.1, and Red Hat Linux Advanced Server
shipped with BIND 9 are are therefore not vulnerable to these issues.
Older releases (6.2, 7.0) of Red Hat Linux shipped with versions of BIND
which are vulnerable to these issues, however a Red Hat security errata in
July 2002 upgraded all our supported distributions to BIND 9.2.1 which is
not vulnerable to these issues."
Okay so the reporter released early and therefore missed out on the full analysis.
This is CAN-2002-0840
Prevent a cross-site scripting vulnerability in the default error page. The issue could only be exploited if the directive UseCanonicalName is set to Off and a server is being run at a domain that allows wildcard DNS. (which are not that common)
The default setting has been Off in 2.0 since 2.0.33; 1.3 has always had it On, so is not vulnerable by default, but is vulnerable if you set UseCanonicalName to Off.
Affects Apache 2.0 all versions including 2.0.42 and 1.3 all versions up to 1.3.26
Expect fixes shortly, but this isn't a very critical vulnerability.
Looks like they've missed a (long) to (int) conversion that happens later which strips the high word and lets you have exact control over the memcpy length.
Although the CNet article tells you otherwise, the open source verison of Apache 2.0 is not available on Monday, and as stated in Apache Week, is only just becoming stable enough for another beta release. Covalent are launching a commercial product that is based on Apache 2.0 but with proprietary extensions (the Apache license unlike the GPL allows this). IBM's httpd server has been based on a 2.0 beta for a number of months. Since Covalent say they've made it Enterprise Ready they must have cured the performance and stability problems, when these get contributed back to the main Apache 2.0 tree everyone wins.
Mark Cox, Red Hat
Yes, Actually the 1.3.22 Announcement that we sent out was exactly the same as the one I initially wrote for Apache Week. Whats the point of writing it twice?
Apache Week explains the changes and highlights the 3 security vulnerabilities fixed by this release
http://petermoulding.com/apacheconeurope2001.html
"Camelot did not pay my fee or expenses for ApacheCon Santa Clara, way back in April, and called today Friday, July 13, at 4:00 am, to say they are closing the company. Camelot appears to have traded while insolvent, a situation that is illegal in some countries."