Message-ID: <006201c39e20$23b2ac40$7b00a8c0@BillDell>
From: full-disclosure at royds.net (Bill Royds)
Subject: Off topic programming thread

I agree that one can write secure code in C, but I am saying that C doesn't
help in writing it.
Perhaps we need to "deprecate" some C standard library functions and syntax
and have the compiler warn us at least when using them, as well as adding
syntax that tells the compiler better the intent of constructs (like const
does) so that it can check for things like out of bounds string risks at the
compile stage.
 In the code that was demonstrated, a good compiler could warn the user that
the cse statement risked goping beyond the end of string at least, without
necessarily adding checking code.

----- Original Message ----- 
From: "Brett Hutley" <brett@...ley.net>
To: "Bill Royds" <full-disclosure@...ds.net>
Cc: "madsaxon" <madsaxon@...ecway.com>; <full-disclosure@...ts.netsys.com>
Sent: Wednesday, October 29, 2003 1:12 AM
Subject: Re: [Full-Disclosure] Off topic programming thread


> Bill Royds wrote:
>
> > A vulnerability on the list today is a perfect example of why C is
> > inherently an insecure programming language and why "thinking in C" is a
> > directo route to insecure code.
>
> *code snipped*
>
> > If instead C allowed a header like
> > static void
> > defang( char* str, char dfstr[dfsize], int dfsize )
> >
> > to indicate to the compiler that string dfstr should never be longer
> > than dfsize, then it could issue the hardware checks (using the CX
> > register in the LOOP instruction). Using C forces the programmer to make
> > no mistakes rather than allowing the compiler to at least warn of
> > possible flaws.
>
> I think what you're really saying is that C allows programmers to make
> mistakes when dealing with areas of memory. The above vulnerability is
> based on a mistake in the code.
> (If I was to code the above prototype BTW, I'd probably make it more
> like "static void defang(const char *str, char *dfstr, unsigned dfsize)"
> to indicate to programmers calling the function that the first
> argument's contents is immutable, the second argument is the destination
> buffer, and the size shouldn't be negative).
>
> Note that you can also create "frameworks" for writing secure code in C
> as well [at least as secure as any bit of code is :) ].
>
> If you were to argue that java has much safer string handling, I'd point
> out that many java environments are written in C and they provide an
> *environment* for working safely with strings. At the end of the day in
> these languages, the string comes down to a C structure and the various
> functions to manipulate the string comes down (or could come down) to C
> functions. Just because the C standard library provides functions like
> strcpy() for working with null-terminated strings doesn't mean you have
> to USE them!! The Windows API, for example, provides it's own string
> routines for working with Unicode/Multibyte strings for example. The GTK
> has another set of string routines and ways of defining a string.
>
> After all, programming languages are just a metadata to generate machine
> code. C has a small vocabulary, with each keyword representing a few
> statements in machine code. Other programming languages generate far
> more machine code per statement, but you have to live within the bounds
> that the language designers have laid out for you. In the case of Java
> you're playing in a sandbox, but if you shovel enough sand you'll come
> across the C structures that create your programming environment :)
>
> Cheers, Brett
> -- 
> Brett Hutley [MAppFin,CISSP,SANS GCIH]
> mailto:brett@...ley.net
> http://hutley.net/brett
>
>

Powered by blists - more mailing lists