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

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

> > Also, I fail to see how most buffer overflows could be a design fault,
> > perhaps you use the word in another sense than the one they've teach in
> > the design courses I've taken.
> Software Design in Swedish would be called "Mjukvaruteknisk Planering". The
> purpose of planning your software architecture is to prevent the birth of
> security holes that are caused by insufficient software planning.

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.

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 :)

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

> A compiler does not change your software design while a "third party"
> executor might,

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

Additionally, many people trust binary-only compilers... If you are really
paranoid, that's not a good thing :)  (to be honest, I'm not that
paranoid)

> and you would be a fool to use untrusted and not fully
> tested libraries.

But, these arguments are the same for a script interpreter. They work the
same and yes, in a few cases you might run into problem if you e.g. update
the interpreter. Just as updating your libraries might cause problems
unless you link staticly. I do not consider perl to be "untrusted and not
fully tested"

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

             http://www.eff.org/cafe