[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Full-Disclosure] Off topic programming thread

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