full-disclosure - No Subject (re: openssh exploit code?)

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: <200310211434.h9LEYTat006506@turing-police.cc.vt.edu>
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: No Subject (re: openssh exploit code?) 

On Tue, 21 Oct 2003 00:22:53 PDT, mitch_hurrison@...lip.com said:
> As far as it being "easy" to exploit. No it isn't. You have to
> abuse a lesser issue, a memory leak to be more precise, to get
> a heap layout that will allow you to survive the initial memset
> without landing in bad memory. Now without going into details
> anyone who manages to survive the initial memset should be able
> to debug the crash to the point of exploitation. This is managable
> on atleast Linux IA32 systems. 

On Tue, 21 Oct 2003 09:21:26 +0200, Michal Zalewski said:
> 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, something
> you really should be aware of before getting in such a flame war. By
> zeroing least significant bytes of certain user pointers on the heap, or
> by overwriting certain malloc structures, it is possible to trigger writes
> to other, somewhat controlled areas of the heap whenever the pointer is
> written or freed, spoof contents when it is read, etc.

> 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.

These paragraphs do more to convince me that the exploit is
possible than all the rest of the flame war put together.  Thanks,
both of you.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031021/4822b1dc/attachment.bin