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
| ||
|
Message-ID: <20031013151610.GF25932@skywalker.bsws.de> 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