Full Disclosure mailing list archives

Re: Re: No Subject


From: Frank Knobbe <frank () knobbe us>
Date: Tue, 21 Oct 2003 02:45:33 -0500

On Tue, 2003-10-21 at 02:21, Michal Zalewski wrote:
While I'd hate to take sides on the OpenSSH vulnerability, this alone is
not a problem. On little endian machines, other than overwriting (zeroing)
variables, you can also benefit from partial pointer overwrite, 

Howdy Michal,

just to clarify, you mean on machines with a paged memory addressing
scheme, right? I mean, byte-order itself is not the catalyst, but the
fact that an address is formed by a page and a pointer within that page,
right? (I'm not nit-picking, just trying to visualize...)

This makes it (sometimes) possible to point the code to a buffer created
previously, for which you control the contents, and can follow the same
procedure, now controlling the entire pointer (or pursue other,
application-specific vectors), triggering writes to stack or such, at
which point, you are home.

Thanks, that actually makes sense to me :)  It seems to be a tricky
undertaking, nudging your way through the heap in order to do something
useful (like overwriting the stack). Then again, probably childs play
for the Halvar Flakes out there...

The million dollar question is: Looking at the code in question for the
SSH heap-0-overwrite, does it appear to be feasible or not? I'm not
looking for a categorically "yes", but for an informed decision based on
the code at hand. Which brings me back to my main issue. There were too
many rumors and broad statements during the time this bug "got press
coverage", but not a real analysis. I was hoping someone would say "Sure
it's exploitable. You overwrite that many bytes over the normal buffer,
overwriting this pointer which cause the previous buffer to do this,
nudging that value over here to finally offset this return address
there." Apparently no one is able or willing to visibly trace the issue.

Oh well... that's been weeks ago now anyway.... 

Thank you for actually responding with useful information (as you
usually do). Seems rather refreshing for this thread :)

Cheers,
Frank

Attachment: signature.asc
Description: This is a digitally signed message part


Current thread: