Full disclosure lets everyone learn from mistakes, as well as forces the vendors to actually fix their damn bugs instead of leaving software you depend on vulnerable until they get around to patching it.

I should say that I am not a fan of 0-day exploit releases. You should at least try to convince the vendor to do the right thing. But failing that, a full disclosure release is the only way to force them to act.

And by full disclosure I do mean a detailed description of the problem, with code demonstrating the exploit.

The problem lies in the fact that computer software has no real automatic failure point. If you buy a car that was poorly designed, and had many flaws, you will find out soon enough when it breaks down. Software won't do that. Once it works, it will keep working for the most part. Yes, it will slowly lose performance if not designed right, but you rarely have catastrophic failure.

The full disclosure movement had an amazing effect on computer security. It made developers accountable for their code. Developers had to come to terms with the fact that code, by nature of existing, is not secure, it does not exist in a vacuum, and, because of that, cannot be left alone indefinitely. In essence, full disclosure created a security field, and made software development better because of it.

However, full disclosure doesn't seem to work any more (at least not the way it is currently done). Simply releasing any and all exploits found makes it easier for anyone to exploit software. When the people running software were experts, and kept on top of keeping their software updated, patched and secure, that wasn't a bad thing. It forced manufacturers to release patches in a timely manner, since people using their code would be expecting the patch. Some place in the past decade and a half, that shifted. Everyone runs software now, and, generally, are the people responsible for keeping it secure.

Optional security patches, when the exploits are publicly available, are not an option. Look at Conficker: the patch actually created interest in the exploit, which created the most recent major security related scare, simply because the patch to fix it was optional, and (evidently) millions of computer operators never took that option. With the huge demand for software, finding skilled, well educated programmers is often not an option. This leads to security issues that developers don't even understand, or even know where to start patching.

Like wise, zero disclosure is also not an option. If zero-day exploits sold in a black market become the norm, it makes it so that only highly organized criminals, or security organizations with deep pockets, will know how exploits work.

The script-kiddie phenomenon is reaching a critical point. When running a bot-net, stealing identities, and all sorts of "hacking" activities require a skill set that qualifies you for a secretary position, something needs to be done about it. Software developers are not testing software adequately. End-users are not patching adequately.

While I don't agree with zero-disclosure, hopefully a shift towards less disclosure may make developers start taking security more seriously from the start. For most users, patching will rarely, if ever, happen. Once developers can't claim that someone else will find security holes later, and hope the users patch them, they may have to start making sure the code they first ship meets some kind of security standards.

They're right. Full disclosure is shifting responsibility away from developers, and onto "security" companies and end users. This is not an inherently good thing, and is currently become a bad thing very quickly.

Why not look at it this way: Companies don't have a financial motivation to spend extra engineering man-hours on security in the absence of full-disclosure.

I think the problem here is that security researchers (and hackers concerned about security in general) believe that security should be a concern of software companies, but they don't realize the prisoner's dilemma that software companies find themselves in. If I run a software company and I spend extra man-hours on security, but my competitor doesn't, and they beat me to market, what do I gain? Will I have enough cash on hand to survive the 2 years it might take for a crippling exploit of their code to arrive and finally give me the market advantage?

In a perfect world all code would be security reviewed, all the hungry children in Africa would have plenty of food to eat, there would be no wars, and John Lennon would still be alive to sing about it all... go figure.

What planet, or more likely, what universe do you live in where 'software rarely have catastrophic failure'? And more importantly, how can I get there as soon as possible? My life would be considerably less miserable in such a place...

Very, very clever way of sending a message out. I'm not a security expert, so I can't judge if full disclosure is bad or good, but I wish they wrote an argument for an alternative to full disclosure.

It's informative because it pretends to imply a little information about how imageshack.us was compromised:

  > anti-sec:~/pwn# perl img-scan.pl

  > Found img1.imageshack.us - lighttpd/1.4.18 - SSH-1.99-OpenSSH_4.5

  >

  > [snip]

  >

  > Found img998.imageshack.us - lighttpd/1.4.18 - SSH-1.99-OpenSSH_4.5

  > anti-sec:~/pwn# perl mass-pwn.pl

Similar to the copy and paste from the OpenSSH 0-day rumor.

This is information voluntarily provided by the perpetrator, apparently. Since this person is interested in "anti-security" and keeping exploit knowledge secret, why would he let on any information about the compromise, including which service was involved in his gain of unauthorized access?

Why go to the effort to make out lighttpd or SSH were involved, when disclosing this goes against his proclaimed agenda?

Because it likely has nothing to do with the compromise, and these guys enjoy starting rumors and watching the effects spread across the internet?

Hmmm, could be?

edit: looks like they have recovered from the hack!