Full Disclosure mailing list archives
Re: Gates: 'You don't need perfect code' for good security
From: "Matthew Murphy" <mattmurphy () kc rr com>
Date: Sun, 2 Nov 2003 15:33:56 -0600
From: "Geoincidents" <geoincidents () getinfo org> wrote: "Matthew Murphy" <mattmurphy () kc 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. ExchangeWhy 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. IISfair 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. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Re: Gates: 'You don't need perfect code' for good security |reduced|minus|none| (Oct 31)
- <Possible follow-ups>
- RE: Gates: 'You don't need perfect code' for good security Beaty, Bryan (Oct 31)
- RE: Gates: 'You don't need perfect code' for good security james (Oct 31)
- RE: [spam] RE: Gates: 'You don't need perfect code' for good security Exibar (Nov 01)
- udp port 2615 Trond Kringstad (Nov 01)
- RE: Gates: 'You don't need perfect code' for good security Cedric Blancher (Nov 01)
- Re: Gates: 'You don't need perfect code' for good security William Warren (Nov 02)
- Re: Gates: 'You don't need perfect code' for good security Matthew Murphy (Nov 02)
- Re: Gates: 'You don't need perfect code' for good security Geoincidents (Nov 02)
- Re: Gates: 'You don't need perfect code' for good security Matthew Murphy (Nov 02)
- Re: Gates: 'You don't need perfect code' for good security Geoincidents (Nov 02)
- Re: Gates: 'You don't need perfect code' for good security George Capehart (Nov 03)
- Re: Gates: 'You don't need perfect code' for good security Geoincidents (Nov 03)
- Re: Gates: 'You don't need perfect code' for good security George Capehart (Nov 03)
- Re: Gates: 'You don't need perfect code' for good security Geoincidents (Nov 04)
- Re: Gates: 'You don't need perfect code' for good security Valdis . Kletnieks (Nov 04)
- Re: Gates: 'You don't need perfect code' for good security Dave Howe (Nov 04)
- Re: Gates: 'You don't need perfect code' for good security George Capehart (Nov 04)
- Re: Gates: 'You don't need perfect code' for good security Nick FitzGerald (Nov 02)
- Re: Gates: 'You don't need perfect code' for good security Valdis . Kletnieks (Nov 02)