From: full-disclosure at royds.net (Bill Royds)
Subject: Off topic programming thread

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@...onet.com 
To: full-disclosure@...ts.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@...ecway.com>
To: <full-disclosure@...ts.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031027/2220a9d4/attachment.html

Powered by blists - more mailing lists