[SC-L] Opinions on strcpy_s, strcat_s, etc.?

2004-09-02 Thread Jared W. Robinson
Who's had experience using the new strcpy_s, etc. functions?
What are your opinions?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure03102004.asp
http://std.dkuug.dk/jtc1/sc22/wg14/www/docs/n1031.pdf

- Jared




Re: [SC-L] Book review - Threat Modeling

2004-08-19 Thread Jared W. Robinson
While the book does have useful information, I'd also encourage people
to read NIST publication 800-30 Risk Management Guide for Information
Technology Systems. I'd like it if the authors of Threat Modeling had
learned a few things from that document -- it would have helped them
improve their book and be more precise about the definitions of certain
concepts.

http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf

or google for it:

http://www.google.com/search?q=Risk+Management+Guide+800-30

- Jared




Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

2004-06-10 Thread Jared W. Robinson
On Wed, Jun 09, 2004 at 03:34:52PM +0100, David Crocker wrote:
 Apart from the obvious solution of choosing another language, there are at least
 two ways to avoid these problems in C++:
 
 1. Ban arrays (to quote Marshall Cline's C++ FAQ Lite, arrays are evil!). Use
 classes from the STL, or another template library instead. Arrays should be used
 only in the template library, where their use can be controlled.
 
 2. If you really must have naked arrays, ban the use of indexing and arithmetic
 on naked pointers to arrays (i.e. if p is a pointer, then p[x], p+x, p-x, ++p
 and --p are all banned). Instead, refer to arrays using instances of a template
 class ArrayX that encapsulates both the pointer (an X*) and the limit (an
 unsigned int).

Unfortunately, I don't think this advice will work for many projects.

First, Many programs must make system calls that only use arrays.
Some of those calls are unsafe.

Second, There is a lot of legacy code written with the error-prone
array indexing that you condemn. While the code must be maintained,
changing it introduces risks of new bugs that lead to instability, and
many people aren't willing to take that risk. So I think your advice
to ban arrays could only be applied to new code, and new projects.
Either that, or the conversion must be made gradually, and must be timed
at the right stage of a maintenance cycle.

- Jared