full-disclosure - Remote Mercury32 Imap exploit

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] [day] [month] [year] [list]

Message-ID: <20041201000615.C7688@dekadens.coredump.cx>
From: lcamtuf at ghettot.org (Michal Zalewski)
Subject: Remote Mercury32 Imap exploit

On Tue, 30 Nov 2004, muts wrote:

> If I'm not mistaken, the point isn't to get a *working exploit* out to
> the public, but more of a proof of concept to point out a vulnerability.
> The only reason to release a *fully* working exploit out to the wild
> would be to get popular amongst the script kiddies. Well done, you're
> popular now :)

Oh really.

People who research and either publish or fix security issues in other
people's code do a service to us all. Regardless of what they deliver, is
it a working exploit or just a vague advisory, for a conscious
administrator, having it is far better than just lettings bugs thrive, and
keeping vendors completely unaccountable. And since these researchers
usually do it for free, they deserve nothing but our respect.

Yes, respect - regardless of what our best guess on their true motivation
is, to that. By a bad analogy: I may believe that Linus Torvalds does his
stuff just to get more attention, pick up chicks, and be able to do less
and get paid more, but this does not mean we should be hating him; and
even if he dares not do things my way and not in a way most convenient to
me at the very moment (gasp!), it is better than not having them done at
all.

Why? Because, get this, even if my accussations were true, he could be
very well spending his time achieving these very goals without giving
anything to others.

This is not to say we should not have discussions and arguments; but there
is a not-so-fine line between constructive criticism and potentially
harmful bashing, and you seem to have crossed it.

This is a sad example that the world today is naive enough to give more
rights and benefits to lazy vendors who, thanks to "responsible"
disclosure they seem to be biggest supporters of, may invest much less and
suffer much fewer side effects of their incompetence or corner-cutting
practices - whereas researchers, instead of being given protection from
frivolous attempts to silence security research by overzealous vendors who
are more concerned about their PR than actual security of their products,
are instead deemed guilty merely because they did not play by some
arbitrary rules imposed by the few.

Responsible disclosure is just a view, and so is full disclosure and
non-disclosure. All of those can be supported by certain oversimplified
arguments, and neither viewpoint is truly superior. But, if on a
full-disclosure list, one chooses to pass as a de facto moral standard a
practice specifically favorable for and favored by companies that would be
best off marginalizing security disclosure and associated publicity - we
have a problem.

-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2004-12-01 00:06 --

   http://lcamtuf.coredump.cx/photo/current/