Skip to content
July 23, 2013 / Rahul Kashyap

Application Sandboxes: A pen-tester’s perspective

I’m excited to announce a new research report from Bromium Labs, written by myself and Rafal Wojtczuk. It ended up being far more comprehensive than we initially thought, so we decided to call it “Application Sandboxes: A Pen Tester’s Perspective”. In this report we perform security evaluation of publicly available application sandboxes viz: Google Chrome, Adobe Reader, Sandboxie, BufferZone Pro and Dell Protected Workspace.

The report is available here.

To create some context, we are all aware of the deficiencies of traditional endpoint security technologies. There are a lot of vendors coming up with ideas and solutions to combat the malware challenge. What is the core issue? It’s simple – the attack surface, which is predominantly the Operating System (and installed apps) for any user. In this paper, we evaluate one of the the newer approaches – sandboxing and verify how well it stands up against real world threats.

The report is about pen-testing and we used and wrote several exploits in our research. However, we did not use any unknown zero days or even try to find vulnerabilities in any of the above mentioned products. That was not needed as the opportunities for attackers are huge already.

Hence, we just stuck to the basics and used exploits (some of which are not public) for known vulns to explore the architectural flaws of sandboxing technology – as you will see after reading the report, sandbox bypasses are unnervingly straightforward using vulnerabilities in the underlying OS.

Not to forget, if we ever encounter a vulnerability in any product, we are committed to responsible disclosure as we’ve always done in the past.

Below is a quick summary of the analysis:


Happy Reading! I look forward to your feedback.

P.S: The Bromium Labs crew will be @BlackHat, Vegas next week in the Exhibit Hall and we’ll demonstrate our analysis with live exploits in action.


Leave a Comment
  1. M Fox / Aug 6 2013 7:23 am

    Sandboxing is hardly new, i have been working with an OS and Application sandboxing tool that is almost 15 years old.
    Nice report, but i do not think you made it clear enough that there is more than one definition of Sandboxing. FireEye has one interpretation- where they use a virtual OS image to learn what the malware might be doing, the “application” sandboxing tested in your report is another, kernel-level sandboxing a third and so on. I would be interested to see how products from McAfee and Symantec fair in your tests with their HIPS products.

    • Rahul Kashyap / Aug 8 2013 9:30 am

      That’s right app sandboxing is hardly new. But it provides an alternative to the detection based model which is proving to be insufficient.

      Hence, our focus was primarily to verify how robust an application sandbox can be for malware containment. As evident with the facts in the report – it’s not good enough. Any new agent on the endpoint should provide measurable security value.

      • Vangrab / Oct 29 2013 8:41 am

        Hi! I still have questions regarding this:
        Sorry guys, but I still need some more explanation-and I did read the entire thread, but you still haven’t answered on the most important questions (I think):
        If you use this configuration on SBIE:
        ProcessGroup=,firefox.exe(whatever browser you use)
        ProcessGroup=,firefox.exe(whatever browser you use)
        ClosedFilePath=%Personal%\My Downloads\(block your personal info from malware)
        ClosedFilePath=%Personal%\My Music\
        ClosedFilePath=%Personal%\My Pictures\
        ClosedFilePath=%My Video%\
        ClosedFilePath=C:\WINDOWS\system32\kernel32.dll(It could say kernel64.dll instead of kernel32.dll)

        If you block access to kernel32.dll and to t2embed.dll and to win32.sys wouldn’t this block all kinds of exploits no matter if you use Firefox, IE 11, or Google Chrome 30, and no matter if you still use Windows XP?

        Also, would SBIE 4 newest version block all of the attempts that those guys tested with that tight configuration above, which blocks access to kernel, t2embed.dll, win32.sys-I mean will it block when that tightly configured against OS Kernel exploits, OS user mode exploits, key-logging (it will when you enable start/run restrictions), Remote Webcam/MIC Access, Clipboard Hijack, screen scraping, network shares access, backdoors and other very real threats?
        Sandboxie 3 was vulnerable to this POC, but Sandboxie 4 is not vulnerable:
        V3 utilizes kernel patching/hooks. V4 was redesigned to alter the permissions (like Untrusted IL on Vista and above) mainly due to Kernel Patch Protection. On XP, some hooks are still being used.

        So what does it mean; does it mean if I understand correctly is that Sandboxie 4 is stronger than v3 because of the operating system that SBIE 4 is used on; like Windows 7 or Windows 8, if it was used on Windows XP SP3 which I still use SBIE is a loser, would SBIE 4 still protect me against this POC that safeguy answered, on Windows XP?

        I must admit I still do not understand what does this all mean and I’m not sure if I understand this all correctly.
        Big thanks to all.
        Also your report is discussed here:

        You can join the community!

      • Rahul Kashyap / Dec 1 2013 11:36 pm


        I tested with SBIE4 and indeed it is quite different and has security improvements over what we tested in our report. Great job by the author!

        However, our kernel exploits still work flawlessly – no issues there. You need to remember that SBIE3/4 (and other similar app sandboxes) are kernel mode drivers and they will always have some fundamental limitations. Blocking access to specific DLL’s is far from a practical use case as you have no idea where the next patch is going to come (BTW similar capability has been available in HIPS technology for several years and very few people use it)

        Once time permits, we’ll probably update our analysis with the latest SBIE4. However, this is not our core focus, the idea of this research was to simply enumerate the fundamental limitations of application sandboxing tech.

        Good Luck!

  2. Vangrab / Dec 13 2013 8:35 am

    Hi, Rahul, thank you for your time and patience,
    I have only one question if it’s true that kernel exploits bypass configured SBIE4, does it mean kernel exploits will overcome products like antivirus/antimalware/firewall, and similar products like Blue Ridge AppGuard, DefenseWall, Comodo, NoVirusThanks EXE Pro with maximum protection and similar?

    If these software products fail to protect against kernel exploits (that you test)-what choice do I have?
    Is there any protection against kernel exploits that you use to test products?

    And AppGuard and DefenseWall and NoVirusThanks exe pro, Comodo also are probably the toughest software products I’ve seen so far-with my experience-but you need a litle bit more configuration to achieve this.

    So what do you think?
    If these sfotware product fail what is your advice to me?
    What exactly should I do?
    Again, thank you for your time and patience Rahul.

    • Rahul Kashyap / Dec 16 2013 4:00 pm

      Hi there,

      We got similar feedback on our paper, people want to know more about other products. Stay tuned for our next research paper! 🙂



  1. Sandbox d’applications : Le point de vue d’un pentesteur | ANSWER IT Security
  2. Much About Nothing New | A Collection of Bromides on Infrastructure
  3. Goodbye FireFox, Welcome Google Chrome |
  4. BlueHat and the new Microsoft | Bromium Labs

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: