[Gllug] C function strcasecmp

[David Spencer]

I didn't mean the NDC caused the BO....look at the sequence of events
below for example.  Sorry I assumed it was obvious that a READ beyond
the end of a buffer was relatively harmless and that a dangerous buffer
overflow meant a WRITE beyond the end of the buffer.

1.display page to user with edit box
2.user fills in edit box
3.program reads edit box into buffer
4.now we strcmp buffer with various options

It is step THREE that risks the buffer overflow (hence the comment "by
the time you're comparing text you've usually already read the text into
the buffer that's just overflowed").  In Losedows, an editbox can hold
32K, or 4G in NT (or is it 2G. It's a lot anyway).  Most temp buffers
are 256, or 1024 long or something like that.  Simply grabbing the
editbox contents into a buffer smaller than the amount the editbox can
hold _without_ considering the length of the text first is where the
buffer overflow happens:

char temp_buf[1024];
GetWindowText(<editbuffer>, temp_buf); suppose this contains 32000
characters
printf("%d",strlen(temp_buf)); will then print 32000

and we see that temp_buf has been well and truly overflowed, and we
haven't even started looking at the contents of temp_buf.  It should be
painfully clear to you by now that any combination of str, n, cmp, case
WILL NOT affect the fact that the buffer has ALREADY BEEN overflowed.

The safe way of coding is as follows:

char temp_buf[1024];
GetWindowTextLen(<editbuffer>);
if (len > 1023) printf("Too much text")   i.e. reject the buffer
contents as too large
or GetWindowText(<editbuffer>, temp_buf, <no more than 1023>);  this
truncates the input text to the buffer size

Then we avoid overflowing temp_buf.

So if you're into software testing, if you come across an edit buffer,
just feed in the entire works of Shakespeare and if the program crashes,
you know it isn't protected against BO.


Oh, and strn* _does_ protect you if it's used correctly; consider the
following:

char x[5];
strncpy(x, "Hello world", 4); (param order?)

No buffer overflow there.


Dave.


home at alexhudson.com wrote:
> 
> On Fri, Jul 20, 2001 at 04:03:12PM +0100, David Spencer wrote:
> > strn(anything) doesn't protect you from buffer overflows; by the time
> > you're comparing text you've usually already read the text into the
> > buffer that's just overflowed.  Checking the size of text in the edit
> > box (or whatever) _before_ reading the text into an appropriately sized
> > buffer is what protects you from buffer overflows.
> 
> I'm not sure how a non-destructive comparison can cause a buffer overflow,
> or how you could compare two strings without knowing their length with
> strncasecmp :), but even so, you are worried about segfaults I s'pose.
> 
> strn.. doesn't _protect_ you, but it enables you to write functions which
> don't overflow buffers, so long as you are capable of reading man pages
> (which most programmers can't.... witness strlcat, etc... :( )
> 
> Cheers,
> 
> Alex.

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug