Re: Off-by-one errors: a brief explanation

["Steven M. Christey" <coley () mitre org>]

[EMAIL PROTECTED] said:

> that wasnt the question- well 'not how can overwritting 5 bytes help
> you', but what error do you code thats a miscount by 5 bytes?

The off-by-one errors I am familiar with have manipulated character
arrays, so each element is one byte long.  When the index is off by
one, you can write one extra byte.

If you have an array of data structures that are 5 bytes each, then an
"off-by-one" error (i.e., off by one *index*) gives you 5 bytes to
work with.  I don't know if any vulnerabilities of this flavor have
been publicized, but I vaguely recall some "classic" buffer overflow
vulnerabilities have involved multi-byte structures instead of
single-byte characters.

However, upon some investigation, it looks like there might be some
inconsistent terminology going around.

The only "off-by-five" error that I could find was reported for sudo
by Global InterSec Research on April 2002:

   BUGTRAQ:20020402 [Global InterSec 2002041701] Sudo Password Prompt
   URL:http://marc.theaimsgroup.com/?l=bugtraq&m=101974610509912&w=2

   original advisory at:

     http://www.globalintersec.com/adv/sudo-2002041701.txt

This problem was *not* due to an index problem, which seems to be the
core of what I call an off-by-one issue.

In this "off-by-five" case, the researchers conclude: "it is possible
to trick sudo into allocating less memory than it should for the
prompt."  In this case, sudo does not properly handle certain
expansion characters in a string, which causes the string to be longer
than expected.

To me, that seems like a different kind of issue than an "off-by-one
index" error, at least as it appears in the source code.

So, the "off-by-five" problem is, in my opinion, a misnomer - at least
from the perspective of the underlying programming error.  From the
exploit perspective, it's fine.

And this is one of the reasons why, at CanSecWest this year, I
mentioned that we need to be more precise about terminology :-)

- Steve