full-disclosure - Off topic programming thread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3FA06451.1080301@hutley.net>
From: brett at hutley.net (Brett Hutley)
Subject: Off topic programming thread

Schmehl, Paul L wrote:

>>-----Original Message-----
>>From: Brett Hutley [mailto:brett@...ley.net] 
>>Sent: Wednesday, October 29, 2003 12:13 AM
>>To: Bill Royds
>>Cc: madsaxon; full-disclosure@...ts.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@...ley.net
http://hutley.net/brett