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

[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 "Array" 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

Re: [SC-L] Interesting article on the adoption of Software Security

[Crispin Cowan]

Damir Rajnovic wrote:
While this is true that only some of the bugs are fixed that fixing can
have unexpectedly high price tag attached. No matter how do you look
at this it _is_ cheaper to fix bugs as soon as possible in the process
(or not introduce them at the first place).
 

This is true in the isolation of looking at the cost of fixing any one 
individual bug, but it is not true in general. Fixing one bug early in 
the process is cheap and easy. Fixing the *last* bug in a system is 
astronomically expensive, because the cost of *finding* bugs rises 
exponentially as you further and further refine it. Worse, you 
eventually reach a point of equilibrium where your chances of inserting 
a new bug in the course of fixing a known bug are about even, and it 
becomes almost impossible to reduce the bug count further.

Personally, I do not see how this can be easily measured.
This entire area is rife with mushy psychological issues involving 
huan's ability to process information correctly. As a result, nearly all 
of the absolute statements are wrong, and they function only within 
certain ranges, .e.g. fixing bugs early in development is cheaper than 
patching in the field, but only within the bounds of digging only so 
hard for bugs.

But even this statement is self-limiting. The above claim is not true 
(or at least less true) for safety-critical systems like fly-by-wire 
systems and nuclear reactor controllers, where the cost of failure due 
to a bug is so high that it is worth paying the extra $$$ to find the 
residual bugs in the development phase.

My reaction to the feuding over whether it is better to shore up C/C++ 
or to use newer safer languages like Java and C#: each has their place.

   * There are millions of lines of existing C/C++ code running the
 world. Holding your breath until they are all replaced with type
 safe code is not going to be effective, and therefore there is
 strong motive to deploy tools (e.g. StackGuard, RATS, etc.) to
 improve the safety of this code.
   * New code should be written in type safe languages unless there is
 a very strong reason to do otherwise.
Crispin
--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix  http://immunix.com

[SC-L] Secure Coding - is that the end of the story?

[Michael S Hines]

We've talked a lot about secure coding - but is that the whole story?

What about other aspects of systems management - memory management
(consuming memory, memory leaks, etc), process management (DDoS, overloading
systems with processes and threads), DASD management (saturating storage
capacity, consumption/saturation of access paths), and auditing management
(filling logs, altering logs, data retention policies)?

Do you know what your systems do at the extreme end points of these
services?  Are they system features that allow you to control and/or monitor
these system aspects?  Can tuning be done dynamically or must it be static
(static meaning rebooting the system to reread configuration data sets).

This link gets to web site performance issues - one aspect of this larger
perspective.
http://www.eweek.com/article2/0,1759,1607765,00.asp

Mike Hines
---
Michael S Hines
[EMAIL PROTECTED] 

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

[Blue Boar]

ljknews wrote:
Okay, that's a bold statement.  I'd better back it up.  If you have a
string-handling library of any kind, someone's going to come up with a
program design that builds a twenty character string for a person's name,
putting first name in the first ten characters, and last name in the last
ten characters.  Eric Smith changes his first name to Navratilova, and he's
suddenly listed by the program as "Navratilovamith amith" - buffer overflow.
Sure, it doesn't overflow into the stack, but it overflows into important
data.
How does the buffer overflow "into important data" using "any language" ?
With Ada and Pascal a 20 character array just has no syntax for storing
a character into the 21st position.  While it is true you will get a
(possibly unanticipated) runtime exception rather than pleasing results,
there is no opportunity for pleasing results in this situation.  The
clever programmer may add an exception handler to display a user friendly
message like "get a name change" rather than the default "index out of
bounds" or whatever.  But neither the clever nor the lazy programmer
gets an overflow "into important data".  The boundary condition is
detected and prevented from causing totally obscure failures.
I think you failed to parse the example provided.  He gave an example 
where he has imposed an arbitrary structure on the built-in string, and 
violated it.  I think he blew the example, as I'm reading it.  I *think* 
he meant:

"Eric  Smith "
becomes
"Navratilovamith "
Thereby blowing his "buffer", and maybe screwing the rest of the program 
logic.  He didn't overflow at the string class level, he did so at the 
logic level.  Or his derived string class, or however you like to think 
of it.

BB

Re: [SC-L] Interesting article on the adoption of Software Security

[Damir Rajnovic]

On Wed, Jun 09, 2004 at 10:37:45AM +0200, Florian Weimer wrote:
> I don't think this is correct.  The costs for fixing bugs is higher
> later in the product lifecycle (and the article cites confirming
> data), but these costs might never materialize.  Only a fraction of
> all bugs are found, and the vendor doesn't even have to fix all those
> which have actually been discovered.

While this is true that only some of the bugs are fixed that fixing can
have unexpectedly high price tag attached. No matter how do you look
at this it _is_ cheaper to fix bugs as soon as possible in the process
(or not introduce them at the first place).

> I've never seen any hard evidence that investment into proactive
> measures during development (or call it "increased software quality")
> pays off in the end, at least in the area of applications which are

Personally, I do not see how this can be easily measured. The only way
we can do that is to say that we used to have so many bugs previoulsy
and fixing them cost that many. Then say that now we have so many
fewer bugs and that brought saving of whatever amount. But all of that
is just a guesswork and not the hard data. The conclusion is that you
can accurately only measure how much fixing cost (and only the technical
part, without trying to estimate lost opportunites and lost customer
confidence) but can not measure the absence of bugs.

The other interesting bit is that, at least at my place, we are seeing
fewer "simple" bugs but more of "complex" one. Not necessarily "complex"
in a sense of how hard is to fix them (but, occasionally, that too) but
that they tend to be more fundamental and far reaching then "simple"
ones. The consequence of it is that, while you may have fewer bugs, the
cost of fixing them stays the same or is even greater then fixing many
"simple" bugs.

Gaus

==
Damir Rajnovic <[EMAIL PROTECTED]>, PSIRT Incident Manager, Cisco Systems
  Telephone: +44 7715 546 033
200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
==
There are no insolvable problems. 
The question is can you accept the solution?