Re: Off topic programming thread

[Brett Hutley <brett () hutley net>]

Schmehl, Paul L wrote:

> > -----Original Message-----
> > From: Brett Hutley [mailto:brett () hutley net] 
> > Sent: Wednesday, October 29, 2003 12:13 AM
> > To: Bill Royds
> > Cc: madsaxon; full-disclosure () lists netsys com
> > Subject: Re: [Full-disclosure] Off topic programming thread
> >
> > I think what you're really saying is that C allows 
> > programmers to make 
> > mistakes when dealing with areas of memory. The above 
> > vulnerability is 
> > based on a mistake in the code.
> > (If I was to code the above prototype BTW, I'd probably make it more 
> > like "static void defang(const char *str, char *dfstr, 
> > unsigned dfsize)" 
> > to indicate to programmers calling the function that the first 
> > argument's contents is immutable, the second argument is the 
> > destination 
> > buffer, and the size shouldn't be negative).
>
> Yes!  This is precisely what I am talking about.
>
> If programmers wrote code like this, then they'd be perfectly justified,
> for example, to simply return an error if dfsize was negative.  After
> all, you were warned. :-)  It would be trivial to check for proper input
> there and simply return an error if it's wrong.
>
> So why isn't this the norm rather than the exception?  Or is it the
> norm?

I don't know what the norm is. Some people write amazingly good code, 
others people write extremely poor code (with all the grays in between). 
On the whole in our company we try to employ more of the former and less 
of the latter. The programmer that will work on a project in general 
depends on many factors - who is available, how important the project 
is, etc. We try and put sensible frameworks in place, like "thou shalt 
purify the application before release" and "if you have made a mistake 
in your checked-in code that basic testing would have found, you have to 
buy everyone on the team coffee".

We're slowly evolving an understanding of what we need to do to improve 
a project's chance of success (ie meeting the user's requirements). Some 
statistics I saw a few years ago gave a 70% chance of *any* large 
software project of failing. It's hard enough finding programmers who 
can build a system that can satisfy the user requirements without trying 
to get programmers familiar with secure programming concepts as well. In 
practice I've found that the few programmers who care enough about 
coding well - the ones that have a well-thumbed copy of "Effective C++" 
or "Design Patterns" on their desks are already starting to learn what 
they need to need to know in order to code securely.

Cheers, Brett
--
Brett Hutley [MAppFin,CISSP,SANS GCIH]
mailto:brett () hutley net
http://hutley.net/brett


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html