full-disclosure - Off topic programming thread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3F9F5A63.4070900@hutley.net>
From: brett at hutley.net (Brett Hutley)
Subject: 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