Re: Gates: 'You don't need perfect code' for good security

["Geoincidents" <geoincidents () getinfo org>]

> 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.

I don't disagree with your reasoning here. I happen to think MS has been
doing well with patch management software (it's required for survival when
your geared for ease of use though) but I still take them to task for the
half assed way they do it sometimes. For example it took Russ from NTbugtraq
to get them to fix windowsupdate so it checked files instead of registry
entries for some of the patches. (thank you Russ!) I actually see some hope
for windowsupdate now. (it's still making mistakes but it's improved from 5
months ago)

> 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.

Fair enough, but my viewpoint is from the perspective of a person who has
literally spent years hacking it and dealing with spammers and everyone else
on the internet trying to hack it and 20+K users pumping mail thru it 24x7.
The only real point you might make is that Exchange is more than just a mail
server, but then windows is more than just a tcp/ip platform and that
doesn't seem to matter when we talk about security so..

> 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.

Now here is an area where we are in violent agreement. It's (security) not
in the code so much as in the design and default config. It's painfully
obvious to me that there are product groups within MS for whom security is
but a passing afterthought. Other groups within MS seem to have it as one of
their main design features that need to be addressed before the first line
of code is written.

>  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.

I have an easy solution for that. If I were a product manager, the test to
go from beta to GA would require the product be put on the net and allow the
world to hack it (as in a very public hacking challenge with a substantial $
reward for hacking it and telling us how you hacked it), when it can stand
up to that for 30 days without being crashed or rooted then it passed the
test.

This would do two things, it would motivate the product team to realize that
if they don't consider security as a requirement to go GA then the product
will never see the light of day and it also provides proof to the public
that it is indeed a secure product and that security is not just a marketing
phrase..

> 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.

I don't see it that way. I think that as a function to run network backups
windows has one of the more secure ways to make connections between
machines. I think MS needs to stop claiming this isn't a feature for the
internet and realize that there is no difference between the internet and
the internal network, both require security unless you somehow don't think
the payroll system requires security..

One of the things that makes me see this differently is that do security for
an ISP, the internet IS our internal network for many machines, as the world
gets more and more connected others are going to realize it's just one big
network and everything on it needs to be protected not only from the rest of
the world but from the machine next door.

Best example I can give you is during the days when the US was being settled
people used to live in forts for safety, but today people realize that
security is not a wall but a way of life. The internet is currently at the
"fort" level of development (firewalled network segments and whatnot) but as
it becomes more and more universal it gets into homes and everywhere then it
should become obvious that everything is going to need to be secure and we
can't depend on build forts for everyone to live in.

> 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.

I'm here to tell you that you can secure a machine without closing those
ports. Let me restate that, if you use those ports you can secure them as
well as you can secure any ports you use on the internet. I agree if they
aren't being used then shutting them down is the best thing and MS needs to
make that easy but some of us actually use them on the open net and in that
case they can be secured as well as anything that's used on the open net.

Are there bugs that allow compromise over them, sure just like there are
bugs that allow compromise over any open port. But my point is this isn't
finger, this is actually something that is useful and I don't want to see it
go away just because of a few exploits. If you have a webfarm full of NT
servers how are you going to back them up over the network if you disable
all windows networking? How are you going to take advantage of windows
domains single login feature if you don't allow machines to talk to each
other? It's like telling a unix admin that because of a few exploits SSH
isn't safe and so it should be disabled. I don't accept that. I want that
functionality and I want it secured not disabled.

> 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.

I'm with you here, most of these types of features are the result of "ease
of use over security" attitude at MS over the years. I believe they have
recently had a major attitude adjustment though so we'll have to give them
some time to see just what effect that has on their mindset. They are now
realizing that security is more important than the ability to include stupid
sound effects and cutesy animations in an email.

> Code Red wouldn't have failed -- possibly Nimda, but not Code Red.

Actually it did, it copied cmd.exe to /scripts/root.exe and it couldn't do
that if it didn't know the actual directory name on disk (\inetpub\scripts)
and would fail to infect those machines although it did still crash the
service.

>  In
> addition, this kind of thing inhibits the ability to quickly reproduce
> changes on multiple machines -- essential for patching.

So what you are saying is that patching my webservers where I have chosen
random install path names fails? That's news to me. <g> What you have missed
here is that the path name is available if you have admin access but during
the exploiting of a machine prior to getting root you don't know the path
name and it makes things measurably more difficult. It adds a level of
security by making it tougher for certain exploits where knowing the default
install path allows you to do things. Any decent hacker will tell you that
knowing the default install paths helps quite often. I'm suggesting a simple
change that takes away this advantage.

Geo.




_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html