From: hb-fulldisclosure at bsws.de (Henning Brauer)
Subject: openssh exploit code?

It's pretty clear that you are wasting our time, I will not go down to 
the level of personal attacks. come back when you have something to 
say.

On Mon, Oct 13, 2003 at 07:09:03AM -0700, security snot wrote:
> 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
> >
> 

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

Powered by blists - more mailing lists