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