Re: It jerked and it berked but the thing really worked!

[Alexander Sotirov <alex () sotirov net>]

On Mon, Feb 23, 2009 at 04:00:32PM -0800, Tal Garfinkel wrote:
> To conclude, this is not production code, and was not intended to be.
> What the fortify guys did is cute - a nice reminder of how easy
> it is to mess up in C- and has no relevance to what the NIST process is about.

The point is that often code that's not intended to be production quality ends
up being used in production environments, especially when we're talking about
the implementation of a crypto algorithm. Let's say that in a few years I'm
given the task of migrating a system to use SHA-3. I'm not a crypto expert,
so I would take the reference implementation and use it with as few
modifications as possible to avoid weakening the crypto by changing something
important.

If Fortify hadn't looked at the code, what are the chances that a buffer
overflow would have found its way into a number of other software projects?
Even if the bug was fixed later, what are the chances of somebody finding
the old reference code with Google and using it?

At what point in the NIST process (or any other development process) do we
start caring about secure coding practices? I believe the right answer is:
before any code is released.

Alex

Attachment: _bin
Description:

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave