From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: Gates: 'You don't need perfect code' for good security

From: "Geoincidents" <geoincidents@...info.org> wrote:
"Matthew Murphy" <mattmurphy@...rr.com> wrote:
>
> > Even though MS, by the time you factor in the large number of components
> > they ship, has had many times fewer patch releases than competing Linux
> > distributions?
>
> Microsoft has been playing a game where they hide exploits then release
> patches that address multiple vulnerabilities with a single patch. This is
> why you see "less" patches. If you count vulns instead of "patches" you'll
> see the game they are playing.

I won't argue there, that's a battle I'll lose ;-)

However, the original poster's point was on patch management -- MS has had
as many bugs as the competing distributions, not really fewer.  I was simply
pointing out the fact that MS had many fewer bulletins to counter those who
say things like "MS releases big patches", etc.

> > 2. Sendmail v. Exchange
>
> Why don't you try Exchange vs NTmail? How many exploits has NTmail had in
> the last 5 years let alone this year (I was the guy publishing the ntmail
> exploits so I've got some idea)? How many have been root level exploits
> (zero). Sendmail is a hole, you pick the absolute worst unix mail server
to
> compare to exchange? Why not compare it to the best? (anything but
sendmail)

You're on target about NTMail, but might I suggest that NTMail is a
lower-profile product than either Exchange *or* Sendmail?  I compared it to
Sendmail because it had (easily) matching market share.

> > 3. Apache v. IIS
>
> fair nough, no complaints with that comparison. You might also compare
BIND
> to Microsoft DNS, Microsoft's has a much much better security record.
> (Stuwart Kwan product manager for W2K's dns knew security when he managed
> that project)

BIND is another example of UNIX code that has been nothing but buggy since
its initial release.  BIND 9 is doing a better job, however.  This is an
excellent comparison, as it allows you to see that BIND had many of the same
problems as recent MS code -- insecure defaults and tendencies.  Really, the
problem isn't that people need to be held responsible for mistakes, it's
that testing and feedback needs to come from greater audiences to eliminate
bugs and unnecessarily insecure design / config.  Unfortunately, the
developers of these projects have not really come up with an effective
method of simulating a strong variety of test environments, short of
full-blown releases.  The result is that the first few years of a product's
code is full of bugs -- just look at IIS 4.0, and the security changes
since.

> > That would be the policy that all networks should use -- firewalling.
>
> Firewalling is an excuse for not closing ports. The only time firewalling
is
> used where it's not an excuse is when you limit certain public IP
addresses
> so that they have access while the rest of the world doesn't.

Yes, unfortunately, firewalling is a poor excuse for port shutdown.  The
fact that out-of-the-box Windows communicates over port 135 is, in my
opinion, a design flaw.  The truth is, one can kill rpcss without having to
worry about much in terms of ordinary functionality.  However, this falls
well short of a non-intrusive method, as some sound players cease to work,
clipboard functionality in some programs fails, etc.

Disabling the file and print sharing server and client bindings will unload
137, 138, and 139 for a given system, but 445 won't shut down without
registry modifications that an ordinary users isn't capable of making.
Similarly, port 135 and other RPC-only endpoints don't shutdown unless you
remove their bindings from the registry.

> > Funny that the same practices, even on an unpatched Windows XP system,
would have
> > been sufficient at blocking the worm.  As long as port 135 the related
> > NetBIOS services (137, 139, 445, 593, etc.) were blocked, this worm
would
> > not make it in.
>
> If the ports are blocked, why are they open at all, what good are blocked
> ports? Is there some reason everyone should have to run MORE software to
> disable other software? Isn't that sort of like letting the worm run on a
> computer but blocking it's outbound access instead of disinfecting the
> machine?

Unfortunately, yes it is.  However, it is the only method that can be
implemented on a wide scale without domain administrative access to the
systems in question.  While it's technically feasible to directly shutdown
all of those ports, it's very difficult on some versions, and methods are
undocumented.

> > I am ignoring your "quality of software" argument, because it is simply
> > moot.  There is little difference in quality of software,
>
> I might agree on strict definition of quality, but default settings are
also
> part of the software and could easily be considered a "quality" issue. The
> best security system in the world is useless if an anonymous user can
> execute code because scripting is available to anyone who sends you an
> email. DEFAULTS ARE CRITICAL.

Yes, defaults are critical, and you also point out the example of the code
base that has the worst security record in MS' history to date: Internet
Explorer.  I believe that there should be options to disable rarely-needed
code like DOM "caching" models.  If you read my last post, yes, I use this
example a lot.  It happens to be the one most insecure, never-needed code
example in IE.

> Really simple change MS could do that would instantly make ALL their
> software more secure (not secure but more secure than it is). Have it
> install to random paths. So instead of everyone knowing right where the
> directories are, each program would install to a random named directory
like
> /program files/program88475 where the number is random. Now things like
> codered would have failed along with dozens of other exploits that rely on
> knowing the path. So simple yet this thought has escaped MS thus far..

Code Red wouldn't have failed -- possibly Nimda, but not Code Red.  In
addition, this kind of thing inhibits the ability to quickly reproduce
changes on multiple machines -- essential for patching.  And, if one was to
install in such a manner, the information about the paths would have to be
kept *somewhere* in order to locate the program again.  Once again, the
system is exploitable.

Powered by blists - more mailing lists