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: <1066684695.464.125.camel@localhost>
From: frank at knobbe.us (Frank Knobbe)
Subject: Re: No Subject

On Mon, 2003-10-20 at 15:43, mitch_hurrison@...lip.com wrote:
> I think you misinterpreted my argumentation. In my eyes
> anyone who is not independently capable of verifying
> the exploitability, or atleast devising the theory
> behind possible exploitation, of the ossh nul overflow
> is a "script kiddie". As you so aptly put it.

Right then. Perhaps that makes me a script kiddie. I just can not
comprehend a case where an unknown area of the heap is overwritten with
0's causes a fault that is exploitable to the point of executing
injected code. I mean, you don't inject code.

The only avenue of attack I see is where you would write 0's into a
certain area of the heap that overwrites some vars of other processes,
such as PAM related stuff. For example, the flag "needauth" gets
overwritten with 0 causing the authentication code to assume "need-auth
is FALSE so user is already auth'ed" and lets the user in or whatever.
But that location on the heap would need to be nailed down. How do you
do that if you can barely control the amount of 0's being overwritten,
but not the location. And it's probably dependent on boot order of
precesses. An exploit this boot may not work after the next boot etc.

I admit that I'm rusty when it comes to assembler (I coded in 65xx and
68xxx years'n'year back, but not Intel). I very well comprehend the
theory behind bo's etc. Perhaps I need to read up on that special
something that makes this ssh issue exploitable. If you have pointers
for heap overflow docs that would apply to this exploit, please pass it
on.


> My original point remains. There is no need for this exploit
> to be disclosed. And I think every ossh admin out there 
> should count himself lucky that he's given the time
> to mend his servers. But do they use this time? No. They
> sit around bitching about not believing it can be exploited
> and will only get off their asses when the proverbial shit
> hits the fan. Now this behaviour is only fueled by uninformed
> openbsd developers trying to save face in calling it "just a dos".

Well, I think you should cut people some slack and not just assume the
extremes. As I said, knowing the true nature of an exploit is beneficial
in "how" you patch the system. The fact that it does need to be patched
is undisputed.

BTW: I'm a FreeBSD guy, and yes, I patched when the source tree was
updated.


> Now at the end of the day it's neither my duty nor my desire
> to release anything. I don't owe you shit. And I'm not about
> to post something that took alot of research just to make a
> moot point.

It is unfortunate that you think so. Forums like FD are the perfect
place to share knowledge. If you rather keep that knowledge to yourself,
fine, just don't bore us with your arrogance. 

If you do want to help the security community, you would do that in a
sensible way. And actually, I agree that posting exploit code
immediately may not be a good thing. But you should share some
information you have. Otherwise what's the point of this list anyway?
It's been over a month now, I think Full Disclosure should finally
happen.

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/20031020/8fd60f66/attachment.bin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ