[thelist] closed source securtiy was: DB Security

[Daniel J. Cody]

Ryan Finley wrote:

> Not sure if I quite agree here...
> 
> If the hole was obvious from the code, then the original programmer would
> have fixed it in the first place!

a buffer overflow is *the* most common exploit in software over the past
15 years. Following this train of thought, the programmer should have
prevented the hole in the first place. But they didnt.. And this is why
MS rightfully gets so much shit. Buffer overflows are explained and
discussed by the 8th week of any decent comp sci program.

> I think that a better metric is:
> 
> The most USED tools have the most attacks, most docs, and imho better "hole
> fixes".

How does a program that is used often have better hole fixes? If the
program was superior in any way, would it not have the holes in the
first place? Especially well known ones?

> Now IIS isn't exactly the most secure webserver...But with the number of
> hackers beating on it every day, it eventually ends being very secure.  As
> long as you keep up with the "hole fixes".

No its not. How many 'hackers' are beting on it every day exactly? How
is the 'beating' making the webserver more secure? Is it really making
it more secure? Very secure??

Seriously.. The big expliot here wasn't found by 'hackers' or anyone
with ill intentions. It was found by a well known security consulting
company that just ran the .exe through a memory profiler and found it
had a buffer overflow. *THE* security exploit of the 80's, 90's, and
today.  

The whole closed vs. open source arguement could go here, and if you
wanna rap about it, I'm cool :)

But really, lets take a look at this situation:

MS and Apache release a new version of their web serving software the
same day, to much fanfare. One week later, a buffer overflow is found in
each piece of software. Now, which software would you rather be running?
Apache, where the moment someone hears about the hole they're working on
a fix because they can see the code, or you yourself could get under the
hood, fix, recompile and be expliot free all in under 10 minutes? Or
would you rather be running IIS where the hole is known(as this one was)
but since the source code isn't readily available you need to wait on MS
to acknowledge, fix, test, and deploy the fix on *THEIR* time?

Eeye informed MS about this two weeks ago, and thats how long it took
for them to roll a patch. You do the math...

End of rant :)

.djc.