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

From: "James P. Salsman" <[email-masked]>
Date: Thu, 2 Aug 2001 21:20:57 -0700 (PDT)

> Date: Tue, 31 Jul 2001 16:32:45 -0400
> From: "David P. Reed" <[email-masked]>
> 
>... I suspect that there are as many *possible* exploits that
> don't need to execute code in the stack as there are not....

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?

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.

Cheers,
James

P.S.  Interix is Microsoft's version of unix for Win2K, which comes 
with a real file system, POSIX .1 and .2, shells, Perl, BSD sockets, 
SVID IPC, Win32api (no WINE required), X11r5, inetd, etc.
  http://www.microsoft.com/WINDOWS2000/interix/

---

From: "David P. Reed" <[email-masked]>
Date: Fri, 03 Aug 2001 09:01:24 -0400

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:
><snip>

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

---

From: "James P. Salsman" <[email-masked]>
Date: Fri, 3 Aug 2001 19:19:09 -0700 (PDT)

David,

Thank you for your message which I guess started from the 
internet-history list, not the ietf discussion list.

>... Lots of programs compile code into a temporary buffer and then execute 
> process a lot of data. 

So, locking the stack against execution would slow graphics applications?
Maybe someone should let Intel know, since they are having a hard time 
convincing consumers that 2 GHz > 1 GHz.  It is pathetic how audio 
applications have been ignored.  Swaying my opinion would require a
different example. 

> Putting the temporary buffer on the stack is *good* 
> memory" in a sensitive part of the system....

On the contrary, there is nothing wrong with a seperate code stack in its 
own segment.

Cheers,
James

---

From: "Meritt James" <[email-masked]>
Date: Mon, 06 Aug 2001 09:32:33 -0400

And you expect them to save "us" from "ourselves"?  Interesting.

-- 
James W. Meritt, CISSP, CISA
Booz, Allen & Hamilton
phone: (410) 684-6566