|
Secure Programming
Off-by-one errors: a brief explanation May 05 2004 07:58PM Steven M. Christey (coley mitre org) (2 replies) Re: [SC-L] Off-by-one errors: a brief explanation May 07 2004 03:19PM Pascal Meunier (pmeunier cerias purdue edu) Re: [SC-L] Off-by-one errors: a brief explanation May 05 2004 10:26PM jnf (jnf datakill org) (1 replies) Re: [SC-L] Off-by-one errors: a brief explanation May 06 2004 10:31AM Yves Younan (yyounan fort-knox org) (2 replies) Re: [SC-L] Off-by-one errors: a brief explanation May 07 2004 02:51PM Mads Rasmussen (mads opencs com br) Re: [SC-L] Off-by-one errors: a brief explanation May 06 2004 11:07AM jnf (jnf datakill org) (1 replies) |
|
Privacy Statement |
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I know how heap overflows work,
I assumed you did, that's why I didn't mention them much, except
pointing out that you were confusing heap and stack overflows in your
explanation: mentioning the 5 byte overflow in the frame pointer
overwrite where you'd need a maximum of 4 bytes in the case of alignment
to 4 bytes.
> 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? I mean, of by one is understandable, but what logic
> error causes you to miscount by 5 bytes?
I was just giving the rationale for describing a 5 byte overflow: if you
have limited space to overflow (for some reason or another), 5 bytes is
the minimum needed in the general case for the heap-based overflow. I
don't know of general cases where you'd explicitly miscount by exactly 5
bytes, but you might misallocate by a small amount of space, still
causing an exploitable vulnerability.
- YY
They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety.
- Benjamin Franklin
[ reply ]