From: deadbeat at sdf.lonestar.org (Daniel)
Subject: openssh exploit code?

touchy..


On Mon, 13 Oct 2003, Henning Brauer wrote:

> Date: Mon, 13 Oct 2003 17:16:10 +0200
> From: Henning Brauer <hb-fulldisclosure@...s.de>
> To: full-disclosure@...ts.netsys.com
> Subject: Re: [Full-Disclosure] 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)
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (NetBSD)
Comment: For info see http://www.gnupg.org

mQGiBDxWfZARBACBQnb2BXzrByAvVKIS1w3Hu4vtgwY/C6hAZrPGDpGcRYnXF7a8
uhquXYQ1IM0AXHwZ0Jca8YSQOVfS6UBojU/ZmkRweQVaa7MEJiRwZ/2dPTG572GY
nM/grv0XVXun/16y+v3tApRwVkrjbHF3k3UgMzRJxmzMSsDT2XSdN2o34wCgw9+D
5faE/kVRlEs5x50ijIcBFcMD/0oMZ1kV3+YVVpXe2CI+If3PSi2+IAvxgFHeEQQB
6nRwmGsVsh6O7kFHagRUScehQgja2IMCtVan7dFmP1CI/k3TsFSf6suiEdTv1sMV
H5N3jJVSAHM6Fm87qhCpeskvdXdkd7n6HPeATmGAaSH3SB3FqVmVq6Qqk/gBK5Qu
t87MA/4wGICDZ6/sx0S3S3NBt2oulTUVQbWIgFhgD9wZAyEO6ruKEk1olba0oAaA
iA+SAf9EY2RyKw9QhosG6Csgqa80VBvkS+rZXBzaaEXfNxuR6MV3cGrs75l+KKI4
tPofUuD643ALLNo4IgxTHWpTD+sabbSCh7e1Meg6BBQuFWSs6bQwRGFuaWVsICho
ZWxvIG5hc3RlZSkgPGRlYWRiZWF0QHNkZi5sb25lc3Rhci5vcmc+iF0EExECAB0F
AjxWfZAFCQDtTgAFCwcKAwQDFQMCAxYCAQIXgAAKCRAaRjzWDUUMXXpVAKCHV7p9
vt4wjcAK2aIodmKrdgrECQCgu0u3f1Tt8VPOIhpyZPqYgmGm+TW5Ag0EPFZ9rhAI
AMHUvRtSXUmwEbqJuS6FfCRZCzqkegv8HOC9kZNjOb8l7mLQ0NFs2E17FpEk9E5A
B2jzX/HDFYiqMJu+xZCfFQMYRMx1KHPCprbM2p4LXJviCTnpEO2FlPiZ54b4s1Dc
56HBfWxLiP9SPCJwWZWEfbqKJI7PnE3kDE+zc7tqhNPyMQZGaWBq1MkTYq9MmM1x
wzOPj4Mv0clL4cpyjI6q4gveIEIkZlHwwVO0bpil+7jrM1dSPOoTuitoKsDy6FvO
+nnqw/VAn/SE1I9H8hsvN17wa2br7LELhEBycVTsHU/qr4KsxAcz77U/5/K47arG
+uM52DoxFpjSpi54Ez83s1cAAwUH/0HSEtOkIETS6jiOKlYFXO/8sOh8yaRr6e9T
+da2UNxTEQDz4nNac8TS0UxrBKXTQf8tVnOYajhEG6ZVD10Xvhn0fv9gc96hEIi3
qY8YRVX/TY/PGtVdOBvQuqWjnkSLP5xbDsBa9vdpM9s2XyaEmJ9aLWSBeeO9Hjd9
v91jxJupH7HqxxvhePEtY/QujT5XIk9p4YPzzhBXMf6jLNqIvEFFeAhoNgheodE6
EuRSfh4YJ8dpIKUQxQTtx/hmbnjMpRT/Fi4AI2KGS0wGR8brs94T4J91u4cYrkzL
r9Bri0gkxj3L9+nEFSrqm0J7ihbW0blqr+8HZxLeNYXDNtfoqdyITAQYEQIADAUC
PFZ9rgUJAO1OAAAKCRAaRjzWDUUMXYlPAKCCZcdDJmlTFCYrBcYoAefYbMEc5ACf
aSJMzYo9ENJ22pd/5nw5c2vxsbI=
=TwPI
-----END PGP PUBLIC KEY BLOCK-----

Powered by blists - more mailing lists