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

Analysis of a Remote Code Execution (RCE) Vulnerability in Cobalt Strike 4.7.1

Command & Control (C2) frameworks are a very sensitive component of Red Team operations. Often, a Red Team will be in a highly privileged position on a target’s network, and a compromise of the C2 framework could lead to a compromise of both the red team operator’s system and control over beacons established on a target’s systems. As such, vulnerabilities in C2 frameworks are high priority targets for threat actors and Counterintelligence (CI) operations. On September 20, 2022, HelpSystems published…

Controlling the Source: Abusing Source Code Management Systems

For full details on this research, see the X-Force Red whitepaper “Controlling the Source: Abusing Source Code Management Systems”. This material is also being presented at Black Hat USA 2022. Source Code Management (SCM) systems play a vital role within organizations and have been an afterthought in terms of defenses compared to other critical enterprise systems such as Active Directory. SCM systems are used in the majority of organizations to manage source code and integrate with other systems within the…

X-Force Research Update: Top 10 Cybersecurity Vulnerabilities of 2021

From 2020 to 2021, there was a 33% increase in the number of reported incidents caused by vulnerability exploitation, according to the 2022 X-Force Threat Intelligence Index. A large percentage of these exploited vulnerabilities were newly discovered; in fact, four out of the top five vulnerabilities in 2021 were newer vulnerabilities. Vulnerability exploitation was the second most common initial infection vector observed by IBM Security X-Force in 2021, falling closely behind phishing. Cybercriminals are finding new ways of bypassing security…

How Log4j Vulnerability Could Impact You

MITIGATION UPDATE: New vulnerability in 2.17 — CVE-2021-44832 Upgrade to 2.17.1 to mitigate this vulnerability Do NOT enable JNDI in any versions Follow: https://logging.apache.org/log4j/2.x/security.html If you hadn’t heard of Apache Log4j, chances are it’s on your radar now. In fact, you may have been using it for years. Log4j is a logging library. Imagine writing your daily activities into a notebook. That notebook is Log4j. Developers and programmers use it to take notes about what’s happening on applications and servers.…