full-disclosure - M$ - so what should they do?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200406220153.i5M1rGff029868@turing-police.cc.vt.edu>
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: M$ - so what should they do? 

On Mon, 21 Jun 2004 18:39:10 EDT, joe <mvp@...ware.net>  said:
> Absolutely, I posted that same message in a MS specific listserv today. My
> comments were along the lines of treat it like a purchased app and set up a
> new team to rebuild the app from the ground up, all new code. That way all
> of the hidden nuggets waiting to bite people are gone and you can say from
> the ground up security is considered. Anything built on old legacy code can
> always be questioned as unsafe given the number of old issues that keep
> popping up even now.

On the other hand, remember that we're talking about 35-50 *million* lines of
code here - that's a massive amount of rewriting that's not generating any
useful income for the company while it's going on. (You unixoids - we're
talking about something on the same scale as redoing the Linux kernel, XFree86,
and Mozilla from the ground up, from scratch).   Estimate how many
programmer-years it took to do it the first time, read Fred Brook's "The
Mythical Man-Month" and apply a suitable adjustment for "second system effect"
(bonus points if you can figure out how much the second system effect added to
the *first* time around ;).

And then realize that all those programmers are basically a boat anchor until
they get finished with the re-write....

Also, to fix many of the design issues will require changing so many APIs and
break so many programs that make use of the old way of doing things that they'd
lose backward compatability.

For instance - getting rid of 'con' as a special file name would remove all
those attacks that depend on 'con.txt' or similar not behaving the way you'd
expect. On the other hand, every single program that assumes that 'prn' gets
you the printer will get b0rked over....

It's not as simple as "throw it out and start again" - what's feasible for a
student's semester project or a small company's small software package isn't as
feasible when it's one of the largest sets of intertwined code ever written....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040621/8722b638/attachment.bin