Obligatory Java “zero-day” Blog Post
When my mother emails to ask if she should be worried about the Java vulnerability the saw on the news, you know a security issue has gone mainstream. And it seems you cannot be a security company without having a blog warning of the dangers presented by the Java exploit – and while it is important that users make sure they are protected against this danger, I wanted to take a step back and make some observations around all of this noise.
People are acting like the advent of a zero day against common software on end users machine is a rare or previously unheard of event. Donald Rumsfeld said it best (or as best you can say it) when he said: There are known knowns; there are things we know that we know. There are known unknowns; that is to say there are things that, we now know we don't know. But there are also unknown unknowns – there are things we do not know, we don't know. It is the first two sentences I want to talk about. This Java vulnerability is a known known – we have all heard of it by now (which be definition means it is not a zero day). The urgency around this issue is due to the fact that until yesterday there was no patch for this vulnerability – though if patching is your first and last line of defense then you have other problems. The lack of a patch highlights the need for defense in depth, so you don’t have to ask your users to follow the steps listed in various blogs out there to disable Java in their browsers.
However this is just a real example of what security professionals have been saying for some time, and they equate with second sentence of Rumsfeld’s quote. Zero days exist, we know they exist we just don’t know which of our systems they work against. When you are a security professional with this mindset you’re designing your security knowing that you don’t have detailed intelligence about the specific vulnerabilities that could be leveraged against you; but you do try and build intelligence about what an attacker would do once they gain access, and you design your systems to contain the threats and trigger alarms as early as possible.
Once you have designed and built those systems you test them with my version of zero days which I have yet to name, perhaps Negative Days? (Though telling people you work with negative days might get depressing.) This testing is not trying to see if you can stop the zero day from being successful, but rather how well your environment is able to detect the intruder once they are in your environment. Another thing I have been pondering is, considering we work under the assumption that a zero day like this has always existed, why are we clamoring for everyone to disable Java in their browsers? Or to put it another way, why would we tell them to turn Java back on when this vulnerability is patched?
Then I was able to figure it out – we are not worried that the zero day is in the hands of a specific team/person out there who researched and found the vulnerability (because we assume they are targeting very specific companies/governments). What has caused this panic is the wholesale distribution of this exploit to every bad guy and bad buy wanna-be out there. The panic occurs not when someone lets us know that (as we had suspected) a zero day is out there, but when that zero day is gift-wrapped. The sad fact is attackers don’t have to go through a change control process before they launch attacks against us, whereas we have to wait for maintenance windows, get proper signoff and approval before we can identify the scope of the risk posed by the latest threat. The security industry has to serve our customers by providing them with a way to be aware of the threats and measure their defenses against them without also arming the attackers. The security race to test and remediate before the bad guys attack is hard enough without someone providing the attackers with nitrous (but considering security is a race I am more than happy when people refer to my product as the Ferrari…)
We follow responsible disclosure at Core; the Zero Day Initiative rewards security researchers for disclosing the issues they find responsibly (and passes the information to other defensive vendors to help them supply protection before the threat is realized.) More and more organizations are offering payment for responsibly disclosed vulnerabilities in their products. What we need is more ways to both inform vendors of known issues in their products and the ability to ensure they release protection in a timely manner; and have an organization we can use to apply pressure when the vendor stalls. Most importantly of all, we should do this without putting people like my mother in harm’s way.
Want to learn about other vulnerabilites?
The CoreLabs team releases an advisory for every vulnerability they discover.