Re: Coopers response to McGraw/Cigital

From: Russ (Russ.Cooper@RC.ON.CA)
Date: 02/26/02


Date:         Mon, 25 Feb 2002 22:24:39 -0500
From: Russ <Russ.Cooper@RC.ON.CA>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

Greg,

Firstly, your premise that people will use the /GS switch and believe
they have solved all of their overrun woes is an assumption that, I
believe, cannot be verified. I accepted that there would be some who
could believe this, but it's a base assumption without any support. You,
and Cigital, seem to be arguing that many people will ascribe to this
belief. You're welcome to your belief but you can no more support it
than you can say it, so let's accept its just an opinion based on no
empirical knowledge rather than trying to stress baseless opinions
(mine's as baseless as yours).

The vulnerability seeder premise is offered by Cigital, and supported by
you, on the contention that if the switch was not available the code
would have undergone some review and the buffer overruns would have been
eliminated. If such actions could have been taken and code not
corrected, then the /GS switch would be irrelevant to the equation. You
say that because its there, code review will not take place and
therefore "legacy code" (and I have no idea why you talk only about
legacy code) will be released in a flawed implementation.

1. If its legacy code, its flawed already if it contains an overrun, so
/GS or not, if its released without code review it will include the
flaws.

2. No promotion is done of the /GS switch, other than in Cigital press
releases, to suggest that it is a solution that allows a coding team to
avoid code review. Ergo, only Cigital and you have suggested that people
will believe this switch is the answer to their problems. Please point
me to the Microsoft documentation that you say coding teams, presumably
reasonably intelligent people, are interpreting as the panacea answer to
their lack of code review.

Finally, I point out a glaringly obvious, but not previously stated
reason for the /GS switch;

If you want to be able to run any sort of test against you code for
buffer overruns, wouldn't it make a whole lot of sense to have something
in your code that allowed you to capture the simplest form of overruns?
I mean, if you could have some sort of overrun handler routine in your
code so that if you trivially overran a buffer, it jumped to a handler,
wouldn't it make it pretty easy to catch those things in your code that
allowed an overrun? Wouldn't it also make sense for this to handle the
most trivial forms of overruns? I mean, if you can catch those, and
eliminate them, don't you make Cigital's two step process irrelevant?

So the compiler vendor makes the switch that allows overrun handler
routines to work. You have to write your own tool to test your input,
how could the compiler vendor do that for you (and have it work properly
all of the time)?? You run your overflow tool against your input points
and see whether any of your input points can overflow, it tests
situations you can't anticipate, like combination input and other things
that commonly lead to overflows not caught by "code review".

You fix those problems, because your handler makes it possible for you
to properly diagnose such things.

Hmm, haven't we raised the bar trivially?

/GS is not "tragically broken". People who make money from performing
code review would have us believe its not possible for coding teams to
write secure code. I think Spaf would disagree, and I know that my good
friend Bob Abbott would argue fervently that we can write secure code.
Do we need review, sure, but does it need to be by a 3rd party or can
helpers like the /GS switch be enough for many?

I think the flaw is in suggesting that more people will think that /GS
fixes all of their woes than those who see it as an assistant to
debugging a problem they've been struggling to figure out.

I still contend that the switch is not flawed, and is not being falsely
promoted by MS. Maybe its not being sufficiently marketed for the values
it can bring, but I'm dieing to hear about the client who believed it
was going to fix all of their buffer overruns and feels robbed by MS
because their insecure coding was still insecure after being compiled
with the switch.

Cheers,
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Delivery co-sponsored by Qualys - Make Your Network Secure
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Go Beyond PARTIAL Security: FREE White Paper

Stop hassling with half-baked ENTERPRISE SECURITY.
FREE White Paper shows you how to ensure TOTAL security for your Internet
perimeter with the most current and most complete PROACTIVE Vulnerability
Assessment solution. Get your FREE White Paper now. Click here!
https://www.qualys.com/forms/techwhite_86.html
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo



Relevant Pages

  • Re: Is this true?
    ... If you're not moving at all, switch off. ... Most vaguely recent cars cut all fuel on the overrun. ...
    (uk.rec.cars.misc)
  • Re: Cigars
    ... We had to switch because alt.politics was overrun by smokers. ... Paul ...
    (alt.smokers.cigars)
  • Re: Coopers response to McGraw/Cigital
    ... <-- snip ... I can't defend that any more than you can, except to say that my opinions were formed through observation of large enterprise environments. ... If its legacy code, its flawed already if it contains an overrun, so ... if its released without code review it will include the ...
    (NT-Bugtraq)