Re: Coopers response to McGraw/Cigital

From: Greg Hoglund (hoglund@CENZIC.COM)
Date: 02/26/02


Date:         Mon, 25 Feb 2002 21:20:22 -0800
From: Greg Hoglund <hoglund@CENZIC.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

Russ, others,

<-- snip
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).
-->

My statements are based on my personal experience. I can't defend that any more than you can, except to say that my opinions were formed through observation of large enterprise environments.

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

Clearly!

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

No intelligent person will perceive the /GS flag as a panacea. Not now.

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

No, it wouldn't. Russ, you said it yourself - the key word is 'trivial'. All it takes is ONE non-trivial worm programmer who codes around that /GS flag. The execution environments of most NT systems are like a monoculture. All it takes is one virus and the whole lot is wiped out. The point is so clear - I don't know what else to say except - it _clearly doesn't work_ .

<-- snip
People who make money from performing
code review would have us believe its not possible for coding teams to
write secure code.
--->

No, I don't think that at all. I can tell what I know is true, however - and that is that large enterprises have very little time, a precious budget, and the current management has 'inherited' millions of lines of code. There are very important and risky vulnerabilities that need to be fixed. The original coders may not even be around anymore. This has nothing to do with your coding skills or mine - it has to do with reality. There aren't very many of us to go around. Code reviews are easy to purchase and if done right, will reveal the risks up front. Most companies don't have enough internal resources to do this in a time-effective manner.

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

That's silly. You cannot possibly compare a code audit with the /GS flag. Hah!

In conclusion, I am not trying to start a flame war w/ you Russ, but my observations need to be understood. It should be obvious that the argument is that /GS is broken and needs to be fixed. In an large enterprise, the most powerful place to have a solution is in development - this is where is costs the least to solve a problem like this. Microsoft is doing the Right Thing by making a compiler-based solution. And, the FACT is that the risk mitigation provided by this 'solution' is not anywhere where it should be for such a powerful point in the development cycle. All I ask is that managers and VP's make informed decisions. Revealing this flaw has helped and will continue to help large enterprises mitigate their risk more effectively.

-Greg Hoglund
CTO, Cenzic, Inc.
http://www.cenzic.com



Relevant Pages

  • Re: Coopers response to McGraw/Cigital
    ... your premise that people will use the /GS switch and believe ... If its legacy code, its flawed already if it contains an overrun, so ... if its released without code review it will include the ... if you could have some sort of overrun handler routine in your ...
    (NT-Bugtraq)
  • Re: How to convert Infix notation to postfix notation
    ... during this code review. ... If you post some code that actually compiles, ... more useful observations. ...
    (comp.lang.c)