Wednesday, November 18, 2015

Windows Sandbox Attack Surface Analysis

Posted by James Forshaw, Quartermaster of Tools

Analysing the attack surface of user-mode sandboxed applications is a good way to hunt for elevation of privilege vulnerabilities. Much of the task of enumerating the attack surface could be done manually, but that’s a very tedious and error prone procedure. Obviously automating that process as much as possible is important both for initial analysis as well as detecting potential regressions.

TL;DR; I’ve released my tools I use internally to test out sandboxed code and determine the likely attack surface exposed to an attacker if a sandboxed process is compromised. You can get the source code from This blog post will describe a few common use cases so that you can use them to do your own sandbox analysis.


Writing a user-mode sandbox is a difficult challenge for various different reasons (see my  Shmoocon/Nullcon presentation I did this year for some examples, in fact I was planning on releasing the tools for Shmoocon but it didn’t happen in time). However in most user-mode implementations, such as Chrome, IE or Edge the sandboxing is done through assigning a restrictive process token so that only a very small number of securable resources can be accessed, ideally no resources at all should be accessible.

An obvious example of a securable resource is the file system. We’d like to know, for example, which locations a sandboxed process can access for read and/or write. A well known tool which comes to mind is AccessChk from Sysinternals ( Microsoft these days). AccessChk allows us to enumerate the security of the file system (as well as many of the secured resources such as the registry or object manager) but only tells you whether you could write to a resource based on a user or group account. For example, running the command ‘accesschk.exe -w users c:\windows’ will show you what files or directories a process that runs with the BUILTIN\Users group can access. However, that doesn’t really help us when it comes to a sandboxed application, which might have a restrictive token that results in a more complex access checking model.

For example, Chrome and Adobe Reader use Restricted Tokens to limit what resources the sandboxed process can access; this changes how the normal kernel access check works. And then there are Mandatory Integrity Labels, which also change what resources you can write to. You can summarise the access check for a restricted token in the below diagram.
Untitled drawing.png

And let’s not forget the introduction of LowBox tokens in Windows 8, which have a similar, but different access checks. And what if you mix both LowBox and restricted tokens? In general this is too complex to replicate accurately; fortunately, Windows provides a means of calculating the granted access to a resource which allows us to to automate a lot of the analysis of various different resources. For that reason I developed my own set of tools to do this which I’ve released as open-source under an Apache v2 license at In the rest of this blog post I’ll describe some of the tools, giving simple examples of use and why you might want to use them.

The Check* Tools

The core of the suite is the Check* tools. Their purpose is to determine whether the process token for a particular sandboxed application can be used to get access to a specific secured resource. For example CheckFileAccess will scan a given location on the file system comparing the Security Descriptor of a file or directory against the process token and determine whether the process would have read and/or write access.

The core to the operation of the tools is the AccessCheck function exposed by the Win32 APIs. This is actually a kernel system call, NtAccessCheck under the hood, and uses the same algorithms as a normal access check performed during the opening of an existing resource. Therefore we can be reasonably confident that the result of operation would match what we’d be able to get access to. The AccessCheck function takes an impersonation token; in this case we’ll use the primary token of a specified process (ideally sandboxed), convert it to an impersonation token, and pass the Security Descriptor for the resource we are interested in. We can then request the kernel determines the maximum allowed permissions for that token.

The following table is a list of the available tools for analysing different types of resources. They all take a command --pid parameter, which specifies the PID of a process to base the security check on.

Checks allowed access to Device Objects such as \Device\HarddiskVolume1
Checks allowed access to the file system.
Checks allowed access to connecting or binding network sockets. This is for testing AppContainer lockdown.
Checks allowed access to resources and directories in the object manager namespace.
Checks allowed access to processes.
Checks allowed access to the registry.

For example if you want to check what files and directories a sandboxed process can write to on the C: drive you can run the following command:
CheckFileAcccess -w -r -p <PID> C:\

The -w parameter specifies only display files or directories with at least one Write permission available (for example Write File, or Add File for directories, or a standard right such as Write DACL). The -r parameter performs the check recursively and the -p specifies the PID of the sandboxed process to test. It’s recommended to run the tool as an administrator as that ensures the tool can recurse into as many directories as possible. If we do this for the Chrome GPU process we find some interesting entries such as being able to write to c:\ProgramData\Microsoft\Windows\DRM.

The CheckDeviceAccess tool deviates from most of the others as it has to actually attempt to open a device node while impersonating the sandboxed token. This is because while the device object itself might have a Security Descriptor, Windows devices by default are considered to be file systems. This means that if you have a device object with the name \Device\Harddisk1 you can also try and access \Device\Harddisk1\SomeName and depending on how the device was registered it might be up to the driver itself to enforce security when accessing SomeName. The only reliable way of determining whether this is the case for a particular device object is to just open the path and see if it works.


A simple example is just to recursively check all Device objects in the object manager namespace using the command:
CheckDeviceAccess -r -l -p <PID> \

The -l parameter will try and map the device name to a symbolic link; this is quite useful for automatically named devices (which look like \Device\00000abc) as the symbolic link is generally more descriptive. For the Chrome renderer sandbox this simple command shows we can access devices such as the NTFS file system driver and AFD (which is the socket driver) but admittedly only if you access it through the namespace. Code running within the Chrome renderer sandbox cannot open any Device object itself.

Of course not all Devices can be tested in this manner; by default, the tool tries to open DeviceName\Dummy but some drivers require a specific path name otherwise they won’t open (you can change Dummy using the --suffix parameter). Still it gives you a quick list of drivers to go hunting for sandbox escape vulnerabilities.

And the Best of the Rest

Not all the tools in the suite are for checking direct access checking, I’ll summarise a few of the other tools which you might find useful.


This tool dumps a list of process mitigations which have been applied through the SetProcessMitigationPolicy API. This only works on Windows 8 and above. Examples of mitigations that could be enabled include Win32k Syscall Disable, Forced ASLR and Custom Font Disable. For example, to dump all processes with Win32k System Call Disable Policy run the following command as an Administrator:
DumpProcessMitigations -t DisallowWin32kSystemCalls


This is a GUI tool which allows you to view the contents of a shared memory section, modify it in a hex editor, and execute a couple of ways of corrupting the section to test for trivial security issues. A section can be opened through its object name or via extracting handles from a running process. I developed this tool for investigating the Chrome section issue I documented in my blog here.



This is just a generic command line tool to dump open handles in all processes in the system. While that in itself wouldn’t differentiate it from other similar tools already available (such as SysInternals Handle utility) it does have one interesting feature. You can group handles by certain properties such as the address of the kernel mode object. This allows you to find instances where an object is shared between two processes at different privilege levels (say between a browser process and its sandboxes tabs) which might allow for privilege escalation attacks to occur. For example running the following command as an Administrator will dump the section objects shared between different Chrome processes.

GetHandles.exe -n chrome -t Section -g object -s partial

This will produce output similar to the following, which shows two section objects shared between different processes:
Object: FFFFC00128086060
11020/0x2B0C/chrome 4/0x4:              Section 00000006 (unknown)
10264/0x2818/chrome 15636/0x3D14:       Section 000F0007 (unknown)

Object: FFFFC00135F82A00
13644/0x354C/chrome 4/0x4:              Section 00000006 (unknown)
10264/0x2818/chrome 11956/0x2EB4:       Section 000F0007 (unknown)

There’s also the CommonObjects tool, which does a similar job but doesn’t have as many other features.


This GUI tool allows you to inspect and manipulate access tokens as well as do some basic tests of what you can do with that token (such as opening files). You can either look at the token for a specific process (or even open token handles inside those processes) or you can create ones using common APIs.



Hopefully these tools will be useful for your own investigations into Windows sandboxes and finding exploitable attack surface. It’s open-source under a permissive license so I hope it benefit the security community and the wider users at large. Still if you have any ideas or changes please consider contributing back to the original project.

Monday, November 2, 2015

Hack The Galaxy: Hunting Bugs in the Samsung Galaxy S6 Edge

Posted by Natalie Silvanovich, Planner of Bug Bashes

Recently, Project Zero researched a popular Android phone, the Samsung Galaxy S6 Edge. We discovered and reported 11 high-impact security issues as a result. This post discusses our motivations behind the research, our approach in looking for vulnerabilities on the device and what we learned by investigating it.

The majority of Android devices are not made by Google, but by external companies known as Original Equipment Manufacturers or OEMs which use the Android Open-Source Project (AOSP) as the basis for mobile devices which they manufacture. OEMs are an important area for Android security research, as they introduce additional (and possibly vulnerable) code into Android devices at all privilege levels, and they decide the frequency of the security updates that they provide for their devices to carriers.

Having done some previous research on Google-made Nexus devices running AOSP, we wanted to see how different attacking an OEM device would be. In particular, we wanted to see how difficult finding bugs would be, what type of bugs we would find and whether mitigations in AOSP would make finding or exploiting bugs more difficult. We also wanted to see how quickly bugs would be resolved when we reported them. We chose the Samsung Galaxy S6 Edge, as it is a recent high-end device with a large number of users.

We decided to work together on a single problem for a week, and see how much progress we could make on the Samsung device. To get our competitive spirits going, we decided to have a contest between the North American and European members of Project Zero, with a few extra participants from other Google security teams to make the teams even, giving a total of five participants on each side.

Each team worked on three challenges, which we feel are representative of the security boundaries of Android that are typically attacked. They could also be considered components of an exploit chain that escalates to kernel privileges from a remote or local starting point.

  1. Gain remote access to contacts, photos and messages. More points were given for attacks that don’t require user interaction, and required fewer device identifiers.
  2. Gain access to contacts, photos, geolocation, etc. from an application installed from Play with no permissions
  3. Persist code execution across a device wipe, using the access gained in parts 1 or 2

A week later, we had the results! A total of 11 issues were found in the Samsung device.

Samsung WifiHs20UtilityService path traversal

Perhaps the most interesting issue found was CVE-2015-7888, discovered by Mark Brand. It is a directory traversal bug that allows a file to be written as system. There is a process running a system on the device that scans for a zip file in /sdcard/Download/ and unzips the file. Unfortunately, the API used to unzip the file does not verify the file path, so it can be written in unexpected locations. On the version of the device we tested, this was trivially exploitable using the Dalvik cache using a technique that has been used to exploit other directory traversal bugs, though an SELinux policy that prevents this specific exploitation technique has been pushed to the device since.

Samsung SecEmailComposer QUICK_REPLY_BACKGROUND permissions weakness

Another interesting and easy-to-exploit bug, CVE-2015-7889 was found in the Samsung Email client by James Forshaw. It is a lack of authentication in one of the client’s intent handlers. An unprivileged application can send a series of intents that causes the user’s emails to be forwarded to another account. It is a very noisy attack, as the forwarded emails show up in the user’s sent folder, but it is still easy access to data that not even a privileged app should be able to access.

Samsung SecEmailUI script injection

James Forshaw and Matt Tait also found a script injection issue in the Samsung email client, CVE-2015-7893. This issue allows JavaScript embedded in a message to be executed in the email client. It is somewhat unclear what the worst-case impact of this issue is, but it certainly increases the attack surface of the email client, as it would make JavaScript vulnerabilities in the Android WebView reachable remotely via email.

Driver Issues

There were three issues found in drivers on the device. CVE-2015-7890, found by Ian Beer, and CVE-2015-7892, found by Ben Hawkes, are buffer overflows in drivers that are accessible by processes that run as media. These could be used by bugs in media processing, such as libstagefright bugs, to escalate to kernel privileges. CVE-2015-7891, found by Lee Campbell of the Chrome Security Team is a concurrency issue, leading to memory corruption in a driver that could be used to escalate from any unprivileged application or code execution to kernel.

Image Parsing Issues

Five memory corruption issues on the device in Samsung-specific image processing by myself, Natalie Silvanovich. Two of these issues, CVE-2015-7895 and CVE-2015-7898 occur when an image is opened in Samsung Gallery, but the three others, CVE-2015-7894, CVE-2015-7896 and CVE-2015-7897 occur during media scanning, which means that an image only needs to be downloaded to trigger these issues. They allow escalation to the privileges of the Samsung Gallery app or the media scanning process.

Severity and Mitigations

Overall, we found a substantial number of high-severity issues, though there were some effective security measures on the device which slowed us down. The weak areas seemed to be device drivers and media processing. We found issues very quickly in these areas through fuzzing and code review. It was also surprising that we found the three logic issues that are trivial to exploit. These types of issues are especially concerning, as the time to find, exploit and use the issue is very short.

SELinux made it more difficult to attack the device. In particular, it made it more difficult to investigate certain bugs, and to determine the device attack surface. Android disabling the setenforce command on the device made this even more difficult. That said, we found three bugs that would allow an exploit to disable SELinux, so it’s not an effective mitigation against every bug.

Reporting the Issues

We reported these issues to Samsung soon after we discovered them. They responded recently, stating that they had fixed eight of the issues in their October Maintenance Release, and the remaining issues would be fixed in November. We greatly appreciate their efforts in patching these issues.

Testing for the vulnerabilities on the same device we found them on, with the most recent security update (G925VVRU4B0G9) applied confirmed this.


The majority of the issues are fixed, however three will not be patched until November. Fortunately, these appear to be lower severity issues. CVE-2015-7898 and CVE-2015-7895 require an image to be opened in Samsung Gallery, which does not have especially high privileges and is not used by default to open images received remotely via email or SMS (so an exploit would require the user to manually download the image and open it in Gallery). The other unfixed issue, CVE-2015-7893 allows an attacker to execute JavaScript embedded in emails, which increases the attack surface of the email client, but otherwise has unclear impact.


A week of investigation showed that there are a number of weak points in the Samsung Galaxy S6 Edge. Over the course of a week, we found a total of 11 issues with a serious security impact. Several issues were found in device drivers and image processing, and there were also some logic issues in the device that were high impact and easy-to-exploit.

The majority of these issues were fixed on the device we tested via an OTA update within 90 days, though three lower-severity issues remain unfixed. It is promising that the highest severity issues were fixed and updated on-device in a reasonable time frame.