Re: Off topic programming thread

["Bill Royds" <full-disclosure () royds net>]

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.

in
----- Original Message ----- 
From: full-disclosure () texonet com 
To: full-disclosure () lists netsys com 
Sent: Monday, October 27, 2003 3:12 PM
Subject: [Full-disclosure] Remote overflow in thttpd


-----------------------------------------------------------------------
Texonet Security Advisory 20030908

There is this C code:


static void
defang( char* str, char* dfstr, int dfsize )
    {
    char* cp1;
    char* cp2;

    for ( cp1 = str, cp2 = dfstr;
   *cp1 != '\0' && cp2 - dfstr < dfsize - 1;
   ++cp1, ++cp2 )
 {
 switch ( *cp1 )
     {
     case '<':
     *cp2++ = '&';
     *cp2++ = 'l';
     *cp2++ = 't';
     *cp2 = ';';
     break;
     case '>':
     *cp2++ = '&';
     *cp2++ = 'g';
     *cp2++ = 't';
     *cp2 = ';';
     break;
     default:
     *cp2 = *cp1;
     break;
     }
 }
    *cp2 = '\0';
}

which attempts to remove the < and > around HTML to prevent HTML injection.

But, since really doesn't have strings in the language, just a convention for 8 bit bytes as pointers, there is no 
length attribute to strings, just a NUL byte at end of an array of characters that is used to check.
The language can't do any checking of to ensure that the output string is not over run because, even though the size of 
the output string is a parameter, the language has no way to limit the size of strings. The programmer made the 
assumption that the check for string pointer within bounds at loop termination check  (cp2 - dfstr < dfsize - 1) was 
sufficient to prevent buffer overflow. Because C does not treat strings as ever having lengths, the compiler can't 
limit the size of the output string with a hardware bounds check (even though there is a hardware instruction on X86 to 
do so). The increment statements can overflow the length of the last character is a ">" of "<" pushing the output 
beyond the length of string dfstr.

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.




----- Original Message ----- 
From: "madsaxon" <madsaxon () direcway com>
To: <full-disclosure () lists netsys com>
Sent: Monday, October 27, 2003 11:44 AM
Subject: RE: [Full-disclosure] Off topic programming thread


> At 09:36 AM 10/27/03 -0600, Schmehl, Paul L wrote:
>
> > > Can we move this irrelevant programming thread somewhere
> > > where it is on-topic?  It may be interesting, but it belongs
> > > on comp.programming or something.  I might be willing to
> > > join in, but it doesn't belong here on FD.
> > I have seen irrelevant stuff on this list.  I fail to see how a
> > discussion of buffer overflows and race conditions in code is off topic.
> > I suspect that many people, including myself, would benefit from a
> > better understanding of how and why they occur, and what needs to be
> > done to fix the problem.
>
> Agreed.  I find this discussion to be one of the more
> on-topic I've seen here. Let's not discourage it, shall we?
>
> m5x
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html