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: [EMAIL PROTECTED]
Sent: Monday, October 27, 2003 3:12 PM
Subject: [Full-Disclosure] Remote overflow in
thttpd
-----------------------------------------------------------------------
Texonet Security Advisory 20030908
Texonet Security Advisory 20030908
There is this C code:
static void
defang( char* str, char* dfstr, int dfsize )
{
char* cp1;
char* cp2;
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';
}
*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 )
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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, October 27, 2003 11:44 AM
Subject: RE: [Full-Disclosure] Off topic programming
thread
>
> > > 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
