Re: C versus other languages, round 538 or so (Re: CGI scriptsinsh)

[Jonathan James <Jonathan () SECURITO SE>]

> Software design is usually at class/module level, and later in the
> design at function level. In my experience I've never seen any design even
> dealing with possible overflow problems; how the programmer assigned a
> certain module implements a function is, usually, an implementation issue
> up to the programmer. Therefore, my opinion is that buffert overflows is
> clearly an implementation problem.
> Design decisions could be, e.g. using other API with easier (safer)
> functions, or designing the confinements. This can realisticly be part of
> the design. Doing a design which prevents programmers from creating
> overflowable functions would somehow have to include the entire code in
> the design, which would make the design impossibly hard to do.

When designing software one has to take into account all the possible
implementation problems that may exist. i.e
1. Read input from user
1.1 Check for null termination
etc..
This is described in pseudo code, no coding needed.

> Another approach could to strictly define "no allowed" functions, such as
> strcpy etc. That would be somewhere in the middle of design and
> implementation I suppose :)
This is the High Level way of doing it, it's not about which functions not
to use but more about understanding the ground zero problem here.
Buffer overflows are not caused by functions but rather from badly written
code.

> The way I understand you, you're of the opinion that all bugs are design
> flaws and none are implementation faults? I really can't agree, esp in
> bigger project. It's a well know factor that different programmers can
> code the same module with very, very different results... ;)

Yes, this is a problem. Perhaps I'm part of a newer coding generation which
includes the implementation part into the design fase.
This ought to be standard practice today.

> Uhmmm... First of, we have the compiler bugs. They aren't really *that*
> rare, but except in certain situation where optimization might cause
> problem for multithreading code (a fellow student got problem with that,
> his code worked in most compilers except a certain one).
My point is that compilers never change the code to a degree that it might
do something that you wouldn't want it to do. (unless you use an
untrusted/homemade compiler). Example:

int function(char *name) {
    char variable[5];
    strncpy(variable, name,5);
    variable[sizeof(variable)] = NULL;
    printf("Hello %s",variable);
    return 0;
}
function("Jonathan James");
This above code will never be compiled in a manner that will let it be
exploitable unless someone has fiddled around with our libraries.

Regards
Jonathan James
http://www.securito.se