Re: Coopers response to McGraw/CigitalFrom: Greg Hoglund (hoglund@CENZIC.COM)
- Previous message: Russ: "Re: Download for MS02-008 available"
- Next in thread: Russ: "Re: Coopers response to McGraw/Cigital"
- Reply: Russ: "Re: Coopers response to McGraw/Cigital"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 25 Feb 2002 11:59:20 -0800 From: Greg Hoglund <hoglund@CENZIC.COM> To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
I think that Russ has some good insight into the vulnerability described - but I also think that Cigital's position is strong. The '/GS' flag needs to be considered from a higher-level and not from a 'down in the weeds' perspective...
There's no arguing that its possible for some coders to think that the
/GS switch may prevent all buffer overruns, ergo, a false sense of
security may be had. I would argue, however, that anyone who believes
this is unlikely to be checking their code for any buffer overruns
anyway, so at worst they will have added *some* protection to code which
is likely insecurely written in the first place.
A coder, or more appropriately, a team of coders working on a project, will be faced with a simple choice - to undertake a painful process of code review and regression tests associated with a great number of point-fixes to code - OR - have the build engineer apply a new switch to 'magically' fix all the legacy programmatical errors. It is not only possible, it is LIKELY that an engineering staff under constraints will choose the 'easy road' and thus the /GS flag is _exactly_ the problem. If the /GS flag actually worked, I would not be stating this. However, as the Cigital team has proven to the world, the /GS flag is Tragically Broken.
[In ref. to McGraw]
Contradicting himself it would seem. Firstly, Cigital did claim that the
/GS switch exposes code to "more attacks", otherwise how could it be
termed a "vulnerability seeder".
Precisely because legacy code that possibly would have been reviewed and treated with best-practices will now be released without the time and sweat investments. Thus, /GS results in more vulnerable code in the marketplace and in the enterprise. McGraw has done us a service in revealing this. Managers within enterprises across the world will now be able to make a more informed choice - they will think, "this '/GS' really doesn't help me... so maybe I need to continue to think about a code-review of this legacy application...". Yes, Microsoft is doing the right thing by trying - but /GS is broken and if someone had not revealed that fact, then code would be using it as a 'panacea'.
Anyone who has followed the art of buffer overflows over the past few years should have a healthy understanding that they are very difficult to eliminate using compiler-options and stack-protection tricks. There are _so_ many ways a buffer overflow vulnerability can exist including exception handler frames, heaps, signed/unsigned conversion errors - Stated flatly, I believe that a compiler _can_ prevent these types of vulnerabilities - but a code-execution architecture that prevents user-supplied data from _ever_ being considered for an instruction would be far better. Too bad it's not going to happen with the x86 family any time soon.
CTO, Cenzic, Inc.
Delivery co-sponsored by VeriSign - The Internet Trust Company
Do you have 128-bit SSL encryption server security?
Get VeriSign's FREE Guide, "Securing Your Web Site for Business," and learn
everything you need to know about using 128-bit SSL to encrypt your
e-commerce transactions, secure your intranets and authenticate your Web
site. 128-bit SSL is serious security for your online business. Get it now!