Re: Microsoft, please protect your stacks (was Re: [ih] ... stack?)

["David P. Reed" <dpreed at reed.com>]

Not sure why I got this(I'm not on ietf.org), but probably I was 
bcc'ed.  It calls for a response, though, if only to oppose a burgeoning 
meme that somehow Microsoft could save us all from hackers if it only did 
one or two simple things.  Those things being techniques that bar perfectly 
sensible coding practices and techniques in order to "save us from hackers".

At 09:20 PM 8/2/01 -0700, James P. Salsman wrote:
> So, Microsoft engineers, if half of all possible exploits might be
> eliminated by changing an MMU flag in the stack segment allocation
> routine(s), why not give it a try on Windows just to say you did?
> <snip>
> The only things certain to break are the CodeRed worm, along with
> all similar stack buffer overflow exploits in any other products,
> and the gdb debugger for Interix.  If you are smart, you can
> probably figure out how to let the user select an executable stack
> for Interix, and whatever other poorly-designed processes which
> also need an executable stack for whatever bizzare reason.

Lots of programs compile code into a temporary buffer and then execute 
it.  The most interesting ones that I know of are in graphics support, 
where various bitblt's and other highly parameterized, highly loopy code 
process a lot of data.  Putting the temporary buffer on the stack is *good* 
design, not bad - using a static buffer requires unnecesary locking, and 
allocating with malloc() means handling the possibility of an "out of 
memory" in a sensitive part of the system.

These tradeoffs were thought of long before Microsoft was dominant, and are 
very common ideas in the serious systems world.  I have no love at all for 
Microsoft, their business practices are often abhorrent, but your 
anti-Microsoft religious views are making you blind to technical judgments 
that are sound and sensible, no matter what O/S we are talking about.

As I said before, the real bad design choice was when somebody put the 
non-validatable strcpy() routine in the C library back at Murray 
Hill.  That's where almost all buffer overflow bugs come from.  Microsoft 
should have just forced programmers not to use it, by removing it from the 
library...  maybe that's their foolish mistake?  In any case, Microsoft's 
programmers should definitely be required to use a sequence involving 
strlen...check bounds...memcpy, which is much safer and essentially the 
same speed (or a modified strcpyn that always forces a null terminated 
result by forcing a null into the last buffer byte).

You probably believe Steve Gibson is right that Microsoft should eliminate 
access to use protocols other than TCP or UDP to prevent DDoS attacks, too.


- David
--------------------------------------------
WWW Page: http://www.reed.com/dpr.html