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

["Bluefish (P.Magnusson)" <11a () GMX NET>]

> 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.

What you *still* haven't explained HOW you do that. We both mentioned the
usage of company/project guidelines on how to write (secure) code. Is this
what you mean? Or do simply mean to have routinely revisions of design and
having the code evaluated for quality assurance? (this is what is known as
iterative development in fancy books [has more names btw], and is standard
in most development companies)

I mean, having the entire code "designed", and not just how modules and
functions interact... Wouldn't this actually mean you have NO design, you
kind of implement it directly?

To me, you speak of some ideal where everything is planned perfectly, the
entire implementation "designed", but you don't actually explain much of
what you actually do.

> 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.

As in the discussion of weather C is too hard or not for experience
programmers, isn't your code broken? :)

>     char variable[5];
>     variable[sizeof(variable)] = NULL;

so, you write to variable[5], which you don't know what it is, as you only
have variable[0..4]. No, this is example isn't exploitable. Perhaps this
actually demonstrate something about experience C programmers and their
trust in their debugging skills. (btw, why are you not using '\0'?)

My message was rather clear about the only real world compiler bug I know
of was with multithreading code. (possibly that one could be abused in a
DoS, if the programmers wasn't aware of the 'feature' in that compiler)

Yes, using a interpreter introduces a dependency in your code. You
consider it widely worse than the dependencies compiled binaries suffer
from, I'm not so sure. Same as with libraries, if they are broken they can
be updated. So can the interpreter. All affected code fixed instantly in
both cases.

..:::::::::::::::::::::::::::::::::::::::::::::::::..
     http://www.11a.nu || http://bluefish.11a.nu
    eleventh alliance development & security team

             http://www.eff.org/cafe