These flaws are made possible at a number of stages. Firstly, we need
to get into the if statement at [A]. This is easy enough to do. The variable
bufsize is the actual size of the buffer we are attacking, which when
using the RETR command is 1024. For the sake of the overflows, we want
to get 'res' to exactly 0. There are a number of possible combinations
to do this, the simplest of which is passing a 1023 byte long buffer
containing a single LF in the first character to the _xlate_ascii_write()
function.


Knowing that we can trigger the if statement we can shift our attention
to session.xfer.buf, the buffer we will be overflowing. The first important
mistake occurs when session.xfer.bufsize is set to 1024 at [B], where
it should actually be 1025 (1023 + CR + NULL). This is followed by the
crux of the overflows at [C]. It is entirely unnessecary to increase
session.xfer.buf here. It essentialy reduces the amount of valid space
in the buffer to 1023. The final significant event leading to the overflows
is at [D], where 1023 bytes of our buffer (including the starting LF)
is moved to session.xfer.buf. Due to the slip-up at [C], we lose our
NULL terminating byte; our buffer is exactly contiguous to the end of
valid space.


The first off-by-one overflow occurs at [E]. The last character of our
1023 byte long argument to _xlate_ascii_write() is moved past the boundary
of allocated space for session.xfer.buf to make room for the preceeding
CR to our LF. We can control this value. We can't, however, control the
next off-by-one at [F]. Due to [C], the line at [F] should be setting
tmpbuf[1022] to NULL. The value at tmpbuf[1023] is what we just oveflowed.
Instead, tmpbuf[1023 + 1] gets set to NULL. Perhaps it would be more
accurate to call this an off-by-two, but as the overflow at [F] existed
even before the ISS bug was patched that would only introduce confusion.