Patching is Broken
Check out this BLOG post by Holly Stewart, senior program manager at Microsoft. It’s about the huge jump in Java based exploits in the past 12 months, having grown from a few tens of thousands to over six million, dwarfing even the Adobe exploit waves that have been hitting in that same period of time. This bit of her post seemed to me to sum things up:
“Back in 2008, the number of Java vulnerabilities started increasing dramatically (one report noted a jump of 264% from 2007 to 2008). Curious, I thought at the time. The main focus of vulnerability protection back then was moving from the OS to the browser, with the next frontiers being malicious documents and movies. I wondered—could Java be on the horizon?”
The question for us is whether this is a trend akin to the tide rising, therefore a paradigm shifting before your eyes - or - a temporary spike in activity that will naturally fall away in time. If the answer is the later it’s simply interesting to read about but if the answer is the former there is a big problem with our current patching infrastructure. It simply isn’t going to cut it.
At the moment I am inclined to suspect the worst, because if we look at the last two years of exploits there is a trend as Holly suggests when she says “protection back then was moving from the OS to the browser, with the next frontiers being malicious documents and movies. Things aren’t moving in a totally random fashion here.
This unwelcome development doesn’t fit into the current model of patching, where OS vendors send out monthly patches through automated update servers. Java and Flash Player are not Microsoft code. Original code bugs from Adobe are built into your browser and there are a couple of big problems with that.
First, the delays in getting Java or Flash Player patched have historically been large. Microsoft put a mountainous effort into creating the machine we think of as patch tuesday. Goodness knows the kind of money that got sunk into that. Granted, Oracle is big too, but we don’t see the same size of effort from these plug-in companies as yet.
Second, there is a structural delay in patching a third party plug-in. It’s one thing to fix the original code, but all that does is release fixed code to Microsoft, Mozilla, Google, Opera and Apple. Whatever form of code that exists in (an SDK perhaps?) has to then be integrated by the browser guys before the end user can get an upgrade. So even if they throw Microsoft sized resource and commitment at the problem it’s always going to leave the customer hanging out to be hacked for a long time.
I wrote last week pointing that as an industry we already leave customers hanging about to be hacked for a minimum of weeks but often for months. Adobe took 179 average days to patch anything last year. But zero day attacks are on the rise. The time it takes to exploit something after a vulnerability has been found is getting shorter, not longer. How can we possibly move to a model where it takes even longer to get code fixes to customer because it tales two steps to fix?
It’s possible we’ll see some kind of innovation from the browser guys. Maybe they’ll build emergency “unplug” technologies so they can institute work arounds whilst we wait for the inevitable delays the system has. Who knows what impact that would have on your internet banking.
Sooner or later something has to give.
Comments
Post new comment