When I was a full-time software developer, one of my colleagues inherited a piece of code that he simply couldn’t make sense of. The thing was a tangled mess of globally defined variables with obscure names that gave no clear indication of their scope; functions spanning hundreds of lines and returning in dozens of places; and goto’s and early exits from loops. For the non-coders, imagine an amalgam of a dirt road and a Los Angeles freeway, with left and right exits — all unmarked — and traveled by BMWs and horse-drawn buggies alike.

He decided that instead of risking breaking the fragile balance of this monstrosity, he left it all alone and preceded every return from the freakish code with a call to his own, sensible functions. Imagine all exits on the highway send you off on a parallel, paved road with separate lanes for different classes of traffic and clearly signed exits.

This is far from the norm in software development. But like one comedian says, somewhere out there is the worst doctor in the world — and someone has an appointment with him tomorrow morning. None of us wants to admit we’re not particularly proficient at our craft, but empirical evidence suggests that the inept are among us. And that’s OK as long as there are checks and balances to compensate.

I’ve written before about secure coding practices. Training programmers on secure coding practices, doing code reviews, and performing automated scans on both source code and the application as it executes need to be part of vendors’ development and quality assurance processes. But consumers need to protect themselves against the residual vulnerabilities.

Case in point: Adobe Acrobat was a favorite avenue of exploitation, which enabled the RSA compromise last year as well as countless other incursions. Now, I’m not saying Adobe writes bad code; rather, Acrobat is ubiquitous, which makes it a tasty target and the bad guys focused much energy on finding flaws in it.

But according to the IBM X-Force 2012 Mid-year Trend and Risk Report “the vulnerabilities in Office and Portable Document Formats (PDF) declined sharply (since the last report).” The report goes on to correlate the decline with the inclusion of sandboxing technology in Adobe Acrobat Reader X.

Sandboxing isn’t a new concept; it’s been used in various forms for some time. Perimeter DMZs are a form of sandboxing, as is segmenting networks with enclave firewalls. Linux/UNIX has had the concept of root jails, or chroot, for some time. Applications have been developed with the concept of separation of privileges for processes and threads. Postfix was written as a secure replacement for Sendmail, substituting Sendmail’s monolithic process model with multiple processes running with minimal privileges, where the main process is the only one that needs to be run as root.

If that sounds like a bunch of techy jibber jabber, imagine the recent presidential national conventions: a big stadium with a bunch of people with widely differing roles and motives. There are the delegates in attendance to cast their votes and drink in the pageantry; the media, there to witness and report the goings-on; the organizers and staff, directing the activities; the nominees and their entourage of family, colleagues and guest speakers; and finally there’s the security detail, trying to keep the whole thing from turning into a recreation of “The Dead Zone.” This is what a typical operating system and all its applications look like: not much in the way of separation or segmentation to keep one angry person with a weapon from bringing down the house.

Now imagine if each of the separate factions had bulletproof, plexiglass domes surrounding them; interconnected as needed by common doors and controlled by a well-trained security guard. It would be impossible to pull out a handgun and fire on the dignitaries, or even the media. However, the media and the delegates will need to communicate and the guard mediates the individual meetings. This reduces the potential for mayhem.

But no security measure is foolproof. Security is not about absolute containment, it’s about deterrence and early detection. People are smarter than turtles and turtles can be blasted difficult to contain. I can think of a half-dozen ways to thwart the cone of silence thingy, but they’re far more involved than the alternative, and will almost certainly require two steps now instead of one: thwart the guard, then cause the intended damage.

Application sandboxes add one more layer of defense in the struggle to regain the right to peaceful enjoyment in our own networks. We already control the infrastructure and can design architectural sandboxing, so it’s important that application providers are putting skin in the security game, particularly because it adds a fair bit to their overhead and little to their direct bottom line.

So kudos to Adobe and others who are investing in sandboxing technology. Time will tell how effective it is in the long term. But at least as consumers are struggling with how to adopt cloud and mobile computing, which challenges my assertion a moment ago that we control our infrastructures, with application and service providers wrapping their own goods in a virtual prophylactic, we won’t feel as option-less when we agree to the EULA. And once they start down the road of building security into their applications, perhaps — just maybe — they’ll come up with a better mousetrap. Sounds like a good name for sandbox 2.0.

More from Software Vulnerabilities

FYSA – Critical RCE Flaw in GNU-Linux Systems

2 min read - Summary The first of a series of blog posts has been published detailing a vulnerability in the Common Unix Printing System (CUPS), which purportedly allows attackers to gain remote access to UNIX-based systems. The vulnerability, which affects various UNIX-based operating systems, can be exploited by sending a specially crafted HTTP request to the CUPS service. Threat Topography Threat Type: Remote code execution vulnerability in CUPS service Industries Impacted: UNIX-based systems across various industries, including but not limited to, finance, healthcare,…

X-Force discovers new vulnerabilities in smart treadmill

7 min read - This research was made possible thanks to contributions from Joshua Merrill. Smart gym equipment is seeing rapid growth in the fitness industry, enabling users to follow customized workouts, stream entertainment on the built-in display, and conveniently track their progress. With the multitude of features available on these internet-connected machines, a group of researchers at IBM X-Force Red considered whether user data was secure and, more importantly, whether there was any risk to the physical safety of users. One of the most…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today