full-disclosure - Re: No Subject

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1066722332.464.175.camel@localhost>
From: frank at knobbe.us (Frank Knobbe)
Subject: Re: No Subject

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031021/60157907/attachment.bin