[linux-elitists] Dateline April 12, 2001 Microsoft: Closed source is more secure

Aaron Lehmann aaronl@vitelus.com
Wed Aug 15 02:16:31 PDT 2001


How much are they paying this guy to troll? I could write more
convincing FUD.

On Wed, Aug 15, 2001 at 01:28:08AM, someone other than Karsten M. Self wrote:
> SAN FRANCISCO--The head of Microsoft's security response team argued
> here Thursday that closed source software is more secure than open
> source projects, in part because nobody's reviewing open source code for
> security flaws.

OpenBSD is, at least. They can't deny that.

> "Review is boring and time consuming, and it's hard," said Steve Lipner,

So is writing software.

> manager of Microsoft's security response center. "Simply putting the
> source code out there and telling folks 'here it is' doesn't provide any
> assurance or degree of likelihood that the review will occur."
> 
> The comments, delivered at the 2001 RSA Conference, were a challenge to
> one of the tenets of open source, that 'with many eyes, all bugs are
> shallow.'
> 
> "The vendor eyes in a security review tend to be dedicated, trained,
> full time and paid," Lipner said.

This is a major philosophical area. If someone is being forced to
write or review code, as a slave to they're job, is he likely to be
less motivated? Bonus question: Will he do a worse job then somebody
working out of passion?

> Lipner argued that network administrators are better off spending their
> time reading log files and installing patches

When I first read this, I thought it was a joke!!

"Spend your time installing patches and reading logs. It's better then
proactively looking for security holes."

Yeah, right.

> "An encryption algorithm is relatively simple, compared to a 40
> million line operating system," Lipner argued. "And the discovery of
> an individual software flaw doesn't pay off much... It doesn't win
> anyone fame and fortune... People fix the flaw and move on."

Stuff like this really interests me, because it applies to their
suggested model of review too. Programmers in commercial settings are
not payed by the number of bugs they find (except in Dilbert). So,
tell me Lipner, WHY would a Microsoft employee feel compelled to find
bugs if it won't give them any direct gain?

To be honest, I don't know. One of the ideas I was considering was
company loyalty, but don't forget the adjective before "employee" in
the question.

> Lipner, who oversees Microsoft's response to newly-reported security
> holes in its products, took the opportunity to point out "the
> repeated and recurring vulnerabilities in the Unix utilities BIND,
> WU-FTP, and so on. The repeated theme is people use this stuff, but
> they don't spend time security reviewing."

Yes. But it's different with Microsoft software. The difference is ...

I forget. Why don't you clue me in?

> Lipner closed by warning that the nature of open source development
> may lend itself to abuse by malicious coders, who could devilishly
> clever 'trapdoors' in the code that escapes detection, hidden in
> plain sight.

BTW, does anybody know if this has *ever* happened? Some histroical
precedent would be interesting. In theory, such a backdoor wouldn't
last long, and its existance time should be inversely proportional to
the popularity of the project (Mozilla DOES NOT COUNT).

> Under polite questioning from the audience, Lipner acknowledged that
> some closed-source commercial products have been found to have
> trapdoors themselves.

YHBT.  YHL.  HAND.


In conclusion, I'd like to expand on the points comparing motivation in
the two settings. It seems to me that in the respective settings your
desire to perform honest review work is driven either by company
loyalty or community loyalty. It is also quite apparent that there
would be many fewer dishonest or lazy reviews actively working in the
free software scene because participation is, of course, optional.
This leaves the argument that there are fewer people reviewing the
code. I do not have data to rebut this argument, so I won't attempt to
do so. I imagine the quality of the collective review depends on the
project size and popularity, which works out nicely as the most
popular projects ought to be the most secure.

Personally I do not think that a large number of people will spend
their time reading code to find bugs. OpenBSD does, but, well, they're
OpenBSD. The pattern that makes more sense to me is people doing
development work, and to a skilled programmer most security bugs will
stand out like a big red <BLINK> tag. It's an interesting, rather
organic/chaotic algorithm for finding bugs: improve the project, and
keep your eyes open along the way.

Now, Microsoft could claim that isn't exhaustive enough. That's good
for them. If they have (1) skilled security-conscious programmers
(2) skilled code reviewers, they obviously aren't using them
effectively. If you proofread every single line of code writen by
already sharp programmers with competent reviewers, that should do a
pretty good job at finding security bugs. But Microsoft's software
has questionable security anyway, so they must be proving that
proofreading every single line of code is not possible even for them
and therefore it isn't practical enough to be applied effectively.

Plus, look at the bug technology advancements in the world. They're on
the free software side. Since source code is available publically,
third parties can review them _in automated ways_. The
Meta-Compilation project at http://hands.stanford.edu/ has done some
amazing work on this front. Their extensible comiler has found
hundreds of crash bugs, locking problems, inappropriate floating point
usages, and potentially exploitable security holes in the Linux kernel
and a few other software packages. Don't believe me? See
http://hands.stanford.edu/linux/ for a great bug database.

Theoretically, it would be possible to sell proprietary metacompilers
to companies who could use them to check their software for bugs, but
I haven't seen this happening, indicating that the free software
community (thanks to Stanford University) is far ahead in this area.



More information about the linux-elitists mailing list