Just how hard it can be to operate a controversial mailing list that frequently sails close to the legal wind was amply demonstrated yesterday when, for the second time in a month, the Full Disclosure mailing list was suddenly shut down. Fyodor, its new operator, announced yesterday:
Sorry I can’t do this anymore. List closed!
Hello everyone. I know I just started the new Full Disclosure list, but
it’s not working out :(. Everything may seem fine from the outside, but it
has been nonstop grief from here. I’m not just talking about the (normal
and expected) troll posts or all the petty complainers. We’ve already
gotten a DMCA takedown demand, two other legal threats, and a sustained DoS
attack which is disrupting all our other services too. And now our ISP is
threatening to shut us down!
It’s kind of embarrassing that John Cartwright lasted 12 years and I
couldn’t even handle a week, but there it is. I do appreciate the many of
you who were supportive.
Then he added, April Fool! “We already have 7,226 members and more than 100 posts in this first week. That includes numerous new vulns, from SQL injection to privacy issues and even a physical security problem. Please keep up the good work!”
This is the headline of a new Google blog: Disclosure timeline for vulnerabilities under active attack. It’s beautiful, and I like to think intentional. On the surface, it simply says that we, Google, are explaining our new timeline for the disclosure of vulnerabilities discovered by our engineers, if they are being actively exploited.
But underneath there is a subtle dig at Microsoft. Microsoft has always demanded a lengthy timeline; and would probably prefer indefinite non-disclosure. Google, however, has always championed a short timeline. It is oh so easy to read this headline as: Microsoft’s disclosure timeline for vulnerabilities is now under active attack by Google.
This new disclosure timeline for actively exploited vulnerabilities is seven days. You cannot fault the logic – with dissidents increasingly targeted by spyware, failure to disclose could potentially be life-threatening. Hell, I would say that it should be a 24 hour timeline. Be that as it may, Google has for now settled on seven days.
And it’s going to be contentious. But here’s the genius. If you’re gonna cause a ruckus, why not get in a sly dig, cloaked in the genius of ambiguous deniability, at the same time?
There are two forms of irresponsible disclosure that are illustrated by the last week in Java world. The first is to rush to full public disclosure as soon as a new vulnerability is discovered or a new exploit developed without giving the vendor any time to fix it. The second is to refuse to disclose until after the vendor has produced a patch. Google’s approach – to give the vendor 30 days to fix the vulnerability before it is made public is responsible disclosure. But I don’t want to defend Google, I want to nail the idea that it is somehow responsible to stay shtum until the fault is officially patched.
Last week a new Java 0-day exploit was made public and went ballistic. The problem is that Oracle knew about the problem from 2 April at the latest: it was a known 0-day vulnerability that Oracle then ignored. Oracle ignored it in its first round of quarterly patches, so the earliest it could fix it would be 16 October (or they could just ignore it again).
An exploit for this vulnerability went public last weekend and was rapidly added to and used by the Blackhole exploit kit – making the internet an even more dangerous place for Java users. But we know that an exploit was active in the wild before it became public knowledge because both Kaspersky and Symantec have said so. What we don’t know is how extensively nor for how long it had been in the wild.
So what we have is an actively exploited 0-day vulnerability that the vendor knew about but had no plans to patch for at least another six weeks – or put another way had already ignored for almost five months. That is unacceptable.
But then the vulnerability was publicly disclosed and shame was heaped upon Oracle. And in just a couple of days it was fixed. This would never have happened without full public disclosure.
So just as giving a vendor no time to fix a vulnerability is irresponsible, so is it even more irresponsible to give that vendor a blank rain check. Oracle and Java prove this – so next time a security researcher publicly discloses a 0-day exploit, don’t condemn the action – it may just save you a whole lot of grief.
Elcomsoft, a Russian cryptanalysis company, has a history of upsetting the West. Way back in 2001, Dmitry Sklyarov, an Elcomsoft programmer, was arrested in the USA after presenting at DEF CON. He had developed a product, The Advanced eBook Processor, that would decrypt encrypted Adobe e-books. He had not broken any US laws while in the USA, nor was his product illegal in Russia. But it certainly upset Adobe and other western publishers at the time.
Today we have a new Elcomsoft product: the Elcomsoft Wireless Security Auditor, complete with WPA2 brute force password cracking. And they’re still upsetting people. Idappcom’s CTO, Roger Haywood, has commented:
…the reality is that the software can brute force crack as many as 103,000 WiFi passwords per second – which equates to more than six million passwords a minute – on an HD5390 graphics card-equipped PC. Furthermore, if you extrapolate these figures to a multi-processor, multiple graphics card system, it can be seen that this significantly reduces the time take to crack a company WiFi network to the point where a dedicated hacker could compromise a corporate wireless network.
Our observations at Idappcom is that this is another irresponsible and unethical release from a Russian-based company that has clearly produced a `thinly disguised’ wireless network hacking tool with the deliberate intention of brute force hacking wireless networks.
The solution is clearly and intentionally priced within the grasp of any hacker or individual intent on malicious wireless attacks. Assuming you have no password and access control recovery system, if you do forget the password to a wireless network that you own, how difficult do you think it is to walk over to the device and press the reset button? In most situations resetting a wireless device, restoring a configuration and setting a new password is a process that can be achieved in minutes.
This is an absolutely valid viewpoint. But I’d like to suggest an alternative view. Was Adobe’s encryption weak in 2001 because of Dmitry Sklyarov; or did/could Dmitry Sklyarov produce his software because Adobe’s encryption was weak? Adobe’s security is far stronger today. Is that partly because of Elcomsoft?
And now, does the Elcomsoft EWSA product create insecure networks, or merely demonstrate that those networks are already insecure? One thing we can be sure of; the security of those WiFi networks will now have to improve. Is that a bad thing?
There is a similarity here with the full disclosure debate. And I suspect that people will take similar sides. You may have guessed that, on balance, I believe that security is improved by full disclosure; and by companies like Elcomsoft. Those who believe that full disclosure is irresponsible disclosure will probably believe that Elcomsoft is irresponsible.
And never the twain shall meet.