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: <Pine.LNX.4.58.0310130640450.1615@cia.zemos.net>
From: booger at unixclan.net (security snot)
Subject: openssh exploit code?

You seriously don't have any idea how, with proper heap manipulation, a
nul overflow can be exploited?  You should stick to writing exploitable
code and leave vuln analysis to the real hackers.

Also your arrogance shows in the same flaming fashion as Theo's homosexual
nature throughout your post.  Again the question of, why is asking for
proof that it is not exploitable any different than demanding proof that
it is exploitable?  I've got nothing to prove to you, and nowhere did I
even claim that I exploited this bug (although, I would be willing to sell
an exploit for the right price).

What're your comments about "with a reasonable malloc" suggesting?  That
under different malloc implementations than the phkmalloc (not written by
your team, hide behind what you cannot do on your own) the bug becomes
exploitable?

Even if that were true (that it's only exploitable under dlmalloc and not
phkmalloc), it's still your bug, and your bug that's being exploitable.
The use of someone elses code as your security buffer hardly seems like
a respectable defense to me.  Not sure about how anyone else on this list
would look at your argument, but then again a lot of subscribers are
idiots who'll be sure to jump to protect your honor.

Under reasonable memcpy implementations, negative length memcpy's aren't
exploitable, but that didn't save you winners did it?

Please, go back to "coding" and let security be in the hands of those who
know what they're doing.  Not you.  Definately not Theo.

I look forward to pissing on the OpenBSD tent at the next security
conference I'm forced to attend (need to get laid once in a while, you
know).  Great tradition more people need to participate in.

You unskilled, clueless little punkass bitch.

-----------------------------------------------------------
"Whitehat by day, booger at night - I'm the security snot."
- CISSP / CCNA / A+ Certified - www.unixclan.net/~booger/ -
-----------------------------------------------------------

On Mon, 13 Oct 2003, Henning Brauer wrote:

> On Mon, Oct 13, 2003 at 12:13:14AM -0700, security snot wrote:
> > Can you provide any sort of technical argument as to why this bug is not
> > exploitable?
>
> sure. look what happens:
>
> 	buffer->alloc += len + 32768;
> 	if (buffer->alloc > 0xa00000)
> 		fatal("buffer_append_space: alloc %u not supported",
> 		    buffer->alloc);
> 	buffer->buf = xrealloc(buffer->buf, buffer->alloc);
>
> the error condition is xrealloc failing.
> xrealloc is a wrapper for realloc, which does proper error checking,
> and calls fatal() on error.
> there is the bug - fatal uses the buffer.
> what happens is basically
> 	bzero(buffer->buf, buffer->alloc);
> as buffer->alloc is already increased, but buffer->buf is still the
> old len, we bzero too much.
> now please explain me how this is exploitable.
>
> > Or are you going to simply stand behind the typical OpenBSD
> > zealot view and say it can't be exploited, only because there is not
> > public "proof of concept" code available?
>
> "I have an exploit but I don't show it", yeah, sure.
>
> we analyzed the bug of course.
>
> don't get me wrong: This is a bug, our action of re-building all
> release sets with the fix was absolutely the way to go (even given it
> was a major PITA and a _lot_ od work), and this is a
> bad bug that should be fixed ASAP, and everybody out there running
> sshd should upgrade/patch asap if not done yet.
>
> However, I absolutely fail to see how this should lead to arbitary
> code execution on a unix system with a reasonable malloc implementation.
> It's a remote DoS.
>
> > ISS' X-Forces claim to have created a working proof-of-concept code for
> > the bug.  Are you calling those respectable young men and woman liars?
>
> if they claim they have an exploit that leads to arbitary code
> execution: yes I do, until we get proof.
>
> I won't answer the rest of your mail which is entirely FUD.
>
> You ask for proof? WHat about YOU proving your statements? Just
> claiming something without any proof is nothing but FUD.
>
> > ps: provide an adequate technical discussion against the exploitability of
> > this particular bug, and if it proves to be sound I'll release an exploit
> > for a different unpublished OpenSSH bug for you guys to write up some
> > advisories on!  (err, must be FUD:)
>
> please do.
> this way it is just FUD.
> prove your claims.
>
> --
> Henning Brauer, BS Web Services, http://bsws.de
> hb@...s.de - henning@...nbsd.org
> Unix is very simple, but it takes a genius to understand the simplicity.
> (Dennis Ritchie)
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ