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