Full Disclosure mailing list archives
Re: Off topic programming thread
From: "Bill Royds" <full-disclosure () royds net>
Date: Mon, 27 Oct 2003 21:11:50 -0500
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
Current thread:
- RE: Off topic programming thread Schmehl, Paul L (Oct 27)
- <Possible follow-ups>
- RE: Off topic programming thread madsaxon (Oct 27)
- Re: Off topic programming thread Bill Royds (Oct 27)
- Re: Off topic programming thread Brett Hutley (Oct 28)
- Re: Off topic programming thread Bill Royds (Oct 29)
- Re: Off topic programming thread Alexandre Dulaunoy (Oct 29)
- Re: Off topic programming thread Brett Hutley (Oct 29)
- Re: Off topic programming thread Bill Royds (Oct 29)
- Auditing code for security problems Bill Royds (Oct 29)
- Re: Off topic programming thread Bill Royds (Oct 27)
- Re: Off topic programming thread Brett Hutley (Oct 29)