An interesting example is where an off-by-one error (CAN 2001-0609, Cfingerd 1.4.3) allowed the joining two buffers together because the NUL byte was never written, and that made a format string vulnerability easier to exploit. http://www.securityfocus.com/archive/1/176087/2004-04-15/2004-04-21/0 http://cert.uni-stuttgart.de/archive/bugtraq/2001/04/msg00223.html
Cheers, Pascal Meunier, Ph.D., M.Sc., CISSP Purdue University CERIAS On May 5, 2004, at 3:58 PM, Steven M. Christey wrote: > > Mads Rasmussen <[EMAIL PROTECTED]> said: > >> I for one have difficulties understanding the "off-by-one" >> vulnerability. Maybe a kind soul would step in? > > I'll try to tackle this. Corrections or additions are most welcome :) > > In general, off-by-one bugs involve small errors in which an array of > size "N" is accessed using an index of N - but since an index is > 0-based in C, the maximum index for the array is N-1. So, N is > actually one byte outside the range of the array. I haven't dug > deeply into the details, but there are probably a couple variants. > > When manipulating strings using functions like strcpy, this means that > the terminating null byte is written outside of the buffer, in some > other memory location that might have security implications if that > null is interpreted as a 0. Or, that memory location is overwritten > after the null was inserted (say, by a string copy to another > variable), so the null character is removed. Then, a function that > processes that string will keep accessing memory until it hits a 0 > byte. > > Functions like strncpy can also be vulnerable to off-by-ones. If the > input is exactly size N, then strncpy doesn't add a terminating null > byte. > > Any kind of C array can be susceptible to off-by-ones, not just > strings. And the use of terminators isn't necessarily required. For > example, if a programmer has an array of data structures, its length > might be stored in a separate variable, rather than relying on a > terminator value to signify the last element of the array. > > The bug isn't always exploitable for code execution. For example, > sensitive data could be leaked from "nearby" memory locations due to a > missing null terminator. > > Some documents that touch on off-by-ones include: > > Halvar Flake's presentation at Black Hat Europe 2001 on "Third > Generation Exploits on NT/Win2k Platforms," which includes buffer > overflows, heap/free() and off-by-one errors: > > > http://www.blackhat.com/presentations/bh-europe-01/halvar-flake/bh- > europe-01-halvarflake.ppt > > This includes a nice graphic representation of the problem at the > stack level, touching on how portions of return addresses can be > overwritten. > > The following Bugtraq post by Vade 79 gives an alternate description > of off-by-ones, along with an example that causes potentially > sensitive memory to be read and copied into a string because of the > missing terminator. > > BUGTRAQ:20030727 [PAPER]: Address relay fingerprinting. > URL:http://marc.theaimsgroup.com/?l=bugtraq&m=105941103709264&w=2 > > The following Bugtraq post by Jedi/Sector One gives something of a > good demonstration if you read between the lines in the code: > > BUGTRAQ:20020624 Apache mod_ssl off-by-one vulnerability > URL:http://marc.theaimsgroup.com/?l=bugtraq&m=102513970919836&w=2 > > In this example, a buffer is allocated 1024 bytes, and there is a > conditional in a loop which tests if i < 1024. However, after > that loop exits, index "i" in the array is modified. > > Olaf Kirch's Bugtraq post "The poisoned NUL byte" seems to be an > early report of the security implications of an off-by-one error: > > BUGTRAQ:19981014 The poisoned NUL byte > URL:http://www.securityfocus.com/archive/1/10884 > > Here are some more source code examples, from Bugtraq posts by > Janusz Niewiadomski: > > BUGTRAQ:20030714 Linux nfs-utils xlog() off-by-one bug > URL:http://marc.theaimsgroup.com/?l=bugtraq&m=105820223707191&w=2 > > BUGTRAQ:20030731 wu-ftpd fb_realpath() off-by-one bug > URL:http://marc.theaimsgroup.com/?l=bugtraq&m=105967516807664&w=2
