Onderwerp: Funny article

"Microsoft Corp. is preparing a major PR assault over Windows' perceived
security failings in which it will criticize Linux for taking too long
to fix bugs, we have learned."

http://www.infoworld.com/article/03/...assault_1.html

--==_Exmh_-50399280P
Content-Type: text/plain; charset=us-ascii

On Wed, 12 Nov 2003 05:24:32 CST, Paulo Ferreira <paulof@bellsouth.net> said:
> "Microsoft Corp. is preparing a major PR assault over Windows' perceived
> security failings in which it will criticize Linux for taking too long
> to fix bugs, we have learned."
>
> http://www.infoworld.com/article/03/...assault_1.html

Hmm.. and the immediately preceding item I got from bugtraq:

= Frontpage Extensions Remote Command Execution
= http ://www.microsoft.com/technet/security/bulletin/ms03-051.asp
.....
= Public disclosure on November 11, 2003

.....
== Credit ==

Discovered and advised to Microsoft January 30, 2003 by Brett Moore of
Security-Assessment.com

Pot. Kettle. You know the drill.


--==_Exmh_-50399280P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQE/soVmcC3lWbTT17ARAudJAJ44JSqNhS1LPOr/5BWvFPtIvDRuIwCffiIl
BvLYtmY70tHoeYFeU7Oun04=
=j79B
-----END PGP SIGNATURE-----

--==_Exmh_-50399280P--

--ADZbWkCsHQ7r3kzd
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

also sprach Paulo Ferreira <paulof@bellsouth.net> [2003.11.12.1224 +0100]:
> "Microsoft Corp. is preparing a major PR assault over Windows' perceived=
=20
> security failings in which it will criticize Linux for taking too long=20
> to fix bugs, we have learned."

i guess the main argument against this joke is that an operating
system with 10 different web servers, 10 different mail servers, 10
different ftp servers, 20 different window managers, 10 different
browsers, 20 different mail clients, and so on, and so on, will have
how many more bugs than a monolithic approach with 1 web server,
1 mail server, 1 ftp server, etc...

the numbers are not exact, but i guess this fact is what microsoft
will exploit. what really counts is numbers on deployed servers, not
bugs in software that very few use...

--=20
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
=20
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
=20
"information superhighway"
is just an anagram for
"i'm on a huge wispy rhino fart".

--ADZbWkCsHQ7r3kzd
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/sovnIgvIgzMMSnURAqZqAKC9Zpc/2Q5TrjkCwUhw7SqFbEXk/ACgquip
wFpeVw8XNBmAV2a0kxKwBf8=
=xHgp
-----END PGP SIGNATURE-----

--ADZbWkCsHQ7r3kzd--

On Wed, 12 Nov 2003, martin f krafft wrote:

> i guess the main argument against this joke is that an operating
> system with 10 different web servers, 10 different mail servers, 10
> different ftp servers, 20 different window managers, 10 different
> browsers, 20 different mail clients, and so on, and so on, will have
> how many more bugs than a monolithic approach with 1 web server,
> 1 mail server, 1 ftp server, etc...

I don't consider the web/mail/ftp servers, windows managers, browsers, mail
clients etc. to be part of the operating system, per se.

Certainly a vulnerability in Apache should not be a strike against Linux,
should it?

I like how the article quoted Steve Ballmer comparing Windows 2000 Server and
W2K3 Server with Red Hat 6. Why doesn't Ballmer compare the state of the art
Windows OS' available at the time RH6 came out? Did Windows NT 4 not stack up
as well against RH6 as W2K/3?

--
Dave Hull
Senior IT Analyst, Information Services
The University of Kansas
voice: (785) 864-0403 || fax: (785) 864-0485

Comparing Microsoft days of risk with linux is apples and oranges. Microsoft
OS's are bundled with their products. Linux has distro'd applications from
multiple vendors. Where is their line there?



-----Original Message-----
From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
Sent: Wednesday, November 12, 2003 11:09 AM
To: Paulo Ferreira
Cc: bugtraq@securityfocus.com
Subject: Re: Funny article

On Wed, 12 Nov 2003 05:24:32 CST, Paulo Ferreira <paulof@bellsouth.net>
said:
> "Microsoft Corp. is preparing a major PR assault over Windows' perceived
> security failings in which it will criticize Linux for taking too long
> to fix bugs, we have learned."
>
> http://www.infoworld.com/article/03/...assault_1.html

Hmm.. and the immediately preceding item I got from bugtraq:

= Frontpage Extensions Remote Command Execution
= http ://www.microsoft.com/technet/security/bulletin/ms03-051.asp
.....
= Public disclosure on November 11, 2003

.....
== Credit ==

Discovered and advised to Microsoft January 30, 2003 by Brett Moore of
Security-Assessment.com

Pot. Kettle. You know the drill.

It would be very interesting to see any results that try to compare
the timeliness of vendor response. I attemped to conduct such a study
a year and a half ago, but the study failed due to lack of time and a
lot of other factors such as:

- the relatively small percentage of disclosure timelines as reported
by researchers - and the number of errors or uncertain values in
some of those timelines (e.g. "I reported this some time ago"). As
a result of this, I was only able to determine a
"notify-to-publish-to-fix" timeline about 10% of the time.

- the relatively large number of bugs that get publicly reported, but
do not seem to be acknowledged or fixed by the vendor(s). Since
there is no publicly known fix, one can only calculate a MINIMUM
amount of time-to-fix.

- the implicit (or explicit) policy that the vendor uses related to
bug severity. For example, a minor information leak may be treated
as a non-security bug whereas a remotely exploitable buffer
overflow would get an instant fix.

- the unknown percentage of bugs that were discovered and fixed by
the vendors themselves. (Indeed, Microsoft's own acknowledgement
policy makes it difficult to know whether their uncredited fixes
are due to their own internal discoveries, or previous public
disclosures by researchers who did not fully coordinate with
Microsoft).

- how one "counts" the number of vulnerabilities. I view this as one
of the main roles of CVE, however any set of vulnerability data
must be normalized in *some* fashion before being compared,
otherwise the stats will be biased.

- how one determines the date when something is "fixed." For
example, consider if the vendor releases a patch that is so broken
that it prevents correct operation of the software. Or consider if
an open source patch is made available at the time of disclosure
and posted to "semi-public" developer-focused lists, but there's
some amount of time before the fix makes it into the official
patch.


I initially tried to cover a 3 month time span, but it really seemed
like at least a year's worth was required.

There were some indications (not statistically proven) that
researchers were generally more willing to coordinate with open source
vendors than closed source. This would further bias any disclosure
data.

You can't simply compare published advisories against each other,
because:

- different vendors have varying criteria for how severe a bug must
be before an advisory is published

- some advisories report multiple bugs, which could mean multiple
disclosure and notification dates, and different times-to-fix

- sometimes an interim patch is provided before the advisory

- sometimes security issues are patched through some mechanism other
than an advisory (e.g. Microsoft's service packs, which fix
security bugs but don't normally have an associated security
bulletin)

- sometimes there are multiple advisories for the same bugs (SCO and
Red Hat immediately come to mind)

You also can't directly compare by "total bugs per OS" because of the
variance in packages that may or may not get installed, plus how one
defines what is or isn't part of the "operating system" as mentioned
previously. One way to normalize such a comparison is to compare
"default" installations to each other, and "most secure" installations
to each other - although of course the latter is not always available.

Fortunately, the percentage of vulnerability reports with disclosure
timelines seems to have been increased significantly in the past year,
so maybe there is a critical mass of data available.

As a final note, I have the impression that most vendors (open or
closed, commercial or freeware) don't track their own speed-to-fix,
and *no* vendor that I know of actually *publishes* their
speed-to-fix.

Hopefully someday there will be a solid public paper that actually
tries to quantify the *real* amount of time it takes to fix bugs,
whether on a per-vendor or per-platform basis, and accounts for all
the issues that I described above. (I know of a couple private
efforts, but they are not public yet.) Of course, one would want to
verify the raw data as well.

- Steve

Steven M. Christey wrote:

> It would be very interesting to see any results that try to compare
> the timeliness of vendor response. I attemped to conduct such a
> study

I would be too.

> a year and a half ago, but the study failed due to lack of time and a
> lot of other factors such as:
(...)

Well, it can be difficult to do compare these times without a common
criteria. From personal experience, I think it is quite possible to
relate some data (date the advisory is release and date the bug was
published) and extract some conclusions. You might have issues with some
specific bugs but, I think, the effects you described are diminished if
you take a bird's view (and cover several years).

> - how one "counts" the number of vulnerabilities. I view this as one
> of the main roles of CVE, however any set of vulnerability data must
> be normalized in *some* fashion before being compared, otherwise the
> stats will be biased.

When I have done this kind of analysis and comparisons I've always used
CVE as the vulnerability count as well as the way to relate data from
different sources (including vulnerability databases such as ICAT and
vendor advisories for example).

(...)

> I initially tried to cover a 3 month time span, but it really seemed
> like at least a year's worth was required.

IMHO the more data you use, the less the effects you described affect
the statistical values you will get.


> You can't simply compare published advisories against each other,
> because:

After all, if they refer to the same CVE names, why not?

> - different vendors have varying criteria for how severe a bug must
> be before an advisory is published

That's not an issue, that is, after all, a vendor decission. However,
bug severities could be determined by independent parties or through a
common formula (see the EISPP Common Advisory Format Description I
pointed to in a previous mail). The raw "time to fix" data could be
partitioned by severity but, still, it could be a useful metric to
compare between vendors.

> - some advisories report multiple bugs, which could mean multiple
> disclosure and notification dates, and different times-to-fix

If advisories refer to different CVE names I don't see that as an issue
either, it just means that different vulnerabilities were fixed at the
same time.

> - sometimes an interim patch is provided before the advisory

That is also a non-issue. Many security bugs can be fixed by appropiate
configuration (or de-activation) of the operating system (i.e.
procedures described in security manuals). Some interim patches just say
'remove the executable' which is not really a fix. If your target is to
determine when a bug gets fixed you should only take into account when
it does really get fixed.

> - sometimes security issues are patched through some mechanism other
> than an advisory (e.g. Microsoft's service packs, which fix security
> bugs but don't normally have an associated security bulletin)

Which is not the best way to distribute security patches since
researches (or IT managers) cannot really know what security bugs are
fixed by what update.

>
> - sometimes there are multiple advisories for the same bugs (SCO and
> Red Hat immediately come to mind)

Many vendors do this. In many cases they release a new version of the
patch fixing issues with it and still refer to the previous
vulnerability. I agree this is a difficult problem since the question
arises: when was the bug really fixed? (in the first advisory or in the
advisories published after it)

> You also can't directly compare by "total bugs per OS" because of the
> variance in packages that may or may not get installed, plus how one
> defines what is or isn't part of the "operating system" as mentioned
> previously. One way to normalize such a comparison is to compare
> "default" installations to each other, and "most secure"
> installations to each other - although of course the latter is not
> always available.

That's why should compare "similar" operating systems. Say, different
Linux distributions, or different propietary UNIX systems, which provide
similar variance of packages and, in many cases, default installations.
Comparing, for example, Microsoft and any UNIX/Linux operating system is
comparing apples to oranges, it might be a good PR move but it seldoms
provide any useful information. For a more thorough discussion I find
point 3, section 4 (Security) in David Wheeler's "Why Open Source
Software / Free Software (OSS/FS)? Look at the Numbers!" [1], very
enlightening.

> Fortunately, the percentage of vulnerability reports with disclosure
> timelines seems to have been increased significantly in the past
> year, so maybe there is a critical mass of data available.

I think there is sufficient data to do proper analysis of
vulnerabilities from many vendors since many already provide accurate
CVE mappings. Microsoft, unfortunately, is not one of those.

>
> As a final note, I have the impression that most vendors (open or
> closed, commercial or freeware) don't track their own speed-to-fix,
> and *no* vendor that I know of actually *publishes* their
> speed-to-fix.
>

That is actually not really true. Debian does this already,
read the FAQ item "How much time will it take Debian to fix
vulnerability XXXX?" in the Security Manual [2]

I've actually tracked the information for Debian this year and published
the results as part of the Debconf3 conference "Security
in Debian: Food for thought and Discussion" [3]

> Hopefully someday there will be a solid public paper that actually
> tries to quantify the *real* amount of time it takes to fix bugs,
> whether on a per-vendor or per-platform basis, and accounts for all
> the issues that I described above. (I know of a couple private
> efforts, but they are not public yet.) Of course, one would want to
> verify the raw data as well.

I also think that this a scientific paper on this issue is long overdue.
It could maybe help clarify some misconceptions, which would be helpful
considering the way this leads to FUD being published by vendors. The
only (outdate) article I've seen which tries to (slightly) address this
issue providing, at the same time, the raw data it used is
"Linux vs. Microsoft: Who Solves Security Problems Faster?" by Jim
Reavis for SecurityPortal [4]. Of course, it takes the Linux vs.
Microsoft stanza which is not the best way to do it, but, still, is much
better than many other FUD articles I've seen out there.

Best Regards

Javi


[1] http://www.dwheeler.com/oss_fs_why.html#security
[2]
http://www.debian.org/doc/manuals/se...#s-debian-sec-
team-faq
[3] Raw data and slides available at
http://people.debian.org/~jfs/debconf/security/, see specifically slide
#8 and #9.
[4]
http://web.archive.org/web/200106081...cover/coversto
ry20000117.html