Much Ado.be About Nothing New

Last week’s shocking admission by Adobe that customer data, including encrypted credit card information for almost 3 million customer accounts, and source code for Adobe Acrobat, which is used to create electronic documents in the PDF format, as well as ColdFusion and ColdFusion Builder – ought to utterly terrify you. The breach itself, discovered as a result of painstaking sleuthing by Brian Krebs and and Alex Holden (ie: Adobe was unaware of the compromise) turns the spotlight on a security vendor that we have to trust absolutely, every time we open a document.

Yes, unfortunately Adobe is a security vendor – one with a spotty security record. Its products process scary MIME types, and include interpreters for executable content such as JavaScript, PostScript and Flash – each of which can be used to execute attacks. The very act of opening an untrusted document requires us to place absolute faith in Adobe’s software.

Beyond the theft of confidential customer data (which is not the subject of this post), the theft of Adobe’s source code is of grave concern: An attacker can now readily examine the Adobe sandbox for vulnerabilities, and write exploit code to specifically target them. Since these by definition would be vulnerabilities that Adobe itself has not spotted, there is nothing that Adobe can do beforehand to prepare for such attacks. Moreover, the massive installed-base of Adobe products means that even if new versions are quickly delivered to patch new exploits, millions of devices will still be vulnerable.

Interestingly, the problem facing Adobe is no different than the (ongoing) problem Oracle faces with Java. And while the Java bashers quickly picked up on the Apple led call for users to “disable client Java”, it really isn’t so easy this time around. Are you ready to ban PDFs from your organization? We need to remind ourselves, yet again, that the massive attack surface of all software sandbox technologies represents a another failed approach to securing the endpoint. Failure of the sandbox is catastrophic for system security.

So, how bad is it? We know that Adobe has adopted the Chrome sandbox, whose source code is already available in open source, developed and tested by a robust community, and further bolstered by Google’s bug-bounty program. In addition, our research has shown that Chrome is the best software sandbox available. While the Adobe implementation leaves the system open to attack in several more ways than Google Chrome, it is my view (contrary to popular hand-wringing) that the availability to attackers of the Adobe sandbox source does not present the industry with an immediate crisis or any radically increased threat. That said, it will be critical for Adobe and the Chrome team to rapidly respond in the event of evidence of attacks in the wild. The key lesson is this: security critical code should be available in open source, and it should be exposed to merciless, continuous testing and review by a community comprising diverse – even competitive – economic interests. It’s a better way to develop better code.

But let’s be generous to Google and Adobe. Let’s assume the sandbox is perfect. What’s scary is that software vendors pretend that sandboxing can help. Even a bug-free sandbox cannot protect a vulnerable endpoint. We have repeatedly shown that malicious code can readily bypass any Windows sandbox using well-known attacks that are impossible for sandbox vendors to protect against. The attacker has more determination and resources than any IT team. So we need a back-stop technology that is vastly more secure than any software containment technique.

Hardware-enforced security will be the next major leap forward in our ability to protect endpoints from attack. We see early signs of this in modern mobile devices, including Windows 8 tablets, which require a TPM (for an attested boot) in order to qualify for the Windows logo. Similar techniques for boot-time security checking are present in iOS. And hardware-enforced security will protect the runtimes of modern OSes and devices too. An early sign of this can be found in a recently granted Apple patent, which describes a way to segregate memory for a “scary application” such as a browser. And as far as I’m aware, the most advanced approach is micro-virtualization. Bromium uses the open source Xen hypervisor to implement micro-virtualization to protect an entire endpoint, but one could just as easily use it to protect a particular targeted application, such as a document renderer, that is vulnerable to attack.

Micro-virtualization, and Bromium vSentry in particular, offers a huge leap forward – making a device vastly more secure because it relies on hardware to contain and isolate untrusted tasks. Most importantly, micro-virtualization works on today’s PCs, laptops and even virtual desktop infrastructure. Once deployed, you can effectively banish concerns you might have about Oracle’s latest foibles, or Adobe’s latest mis-step. You can achieve practical, hardware-enforced security now, and stop worrying about the latest zero-day, browser vulnerability, PDF or Office-based attack. And then you can empower your users to be mobile and access the full power of the web.

While no system can ever be perfect, it is easy to show how vSentry makes an endpoint tens of thousands of times more resilient to attack. It doesn’t rely on pre-conceived notions of good or bad, it works with software sandboxes, and all of your existing investments in endpoint and network security. Dramatically increasing the cost to the attacker by massively reducing the attack surface of the system has the net effect of making it too expensive for an attacker to compromise a hardware protected endpoint.

There is no silver bullet in security, but there is a very simple set of steps you can take to achieve a massively more secure endpoint posture that allows you to relax in the face of continued software vendor missteps.