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/cred.zip 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.

Android Developer Story: PicMix reaches global audience on Google Play


Posted by Lily Sheringham, Google Play team

Inovidea Magna Global, is the developer of PicMix, a photo and video editing app, which has now evolved into an interest based social media platform powered by content discovery and social commerce. It has 27 million users worldwide, 65% of which are outside of its home market in Indonesia.

Hear Calvin Kizana, CEO, and Sandy Colondam, Co-founder, explain how they used Google Play tools, such as Store Listing Experiments and Material Design, to create a high quality app which appeals to a global audience.

Learn more about store listing experiments and find out how to get started with Material Design. Also, get the Playbook for Developers app and stay up-to-date with more features and best practices that will help you grow a successful business on Google Play.

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 https://github.com/google/sandbox-attacksurface-analysis-tools. 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 https://github.com/google/sandbox-attacksurface-analysis-tools. 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 \Device000abc) 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.

Extending Web Technology with Android


Developer guest post by Active Theory

Paper Planes started as a simple thought – “What if you could throw a
paper plane from one screen to another?”

The heart of our concept was to bring people together from all over the world,
using the power of the web – an instant connection to one another. Modern web
technology, specifically JavaScript and WebGL, powered the experience on every

was initially featured at Google I/O 2016, connecting attendees
and outside viewers for 30 minutes preceding the keynote. For the public launch
on International Peace Day 2016, we created an Android
Experiment, which is also featured on Google
Play, to augment the existing web technology with native Android Nougat
features such as rich notifications when a plane is caught elsewhere in the


Users create and fold their own plane while adding a stamp that is pre-filled
with their location. A simple throwing gesture launches the plane into the
virtual world. Users visiting the desktop website would see their planes flying
into the screen.

Later, users can check back and see where their planes have been caught around
the world. Each stamp on the plane reads like a passport, and a 3D Earth
highlights flightpath and distance travelled.

In addition to making their own planes, users can gesture their phone like a net
to catch a plane that has been thrown from elsewhere and pinch to open it,
revealing where it has visited. Then they can add their own stamp, and throw it
back into the flock.


We developed Paper Planes to work across devices ranging from the 50-foot screen
on stage at Google I/O to desktop and mobile using the latest in web technology.


From the stylized low-poly Earth to the flocking planes, WebGL is used to render
the 3D elements that power the experience. We wrote custom GLSL shaders to light
the Earth and morph targets to animate the paper as the user pinches to open or


When a user “throws” a plane a message is sent over websockets to the back-end
servers where it is relayed to all desktop computers to visualize the plane
taking off.


The plane flocking simulation is calculated across multiple threads using
WebWorkers that calculate the position of each plane and relay that information
back to the main thread to be rendered by WebGL.

To create an experience that works great across platforms, we extended the web
with native Android code. This enabled us to utilize the deep integration of
Chromium within Android to make the view layer of the application with the web
code that already existed, while adding deeper integration with the OS such as
rich notifications and background services.

If you’re interested in learning more about how to bridge WebView and Java code,
out this GitHub repo for a tutorial.


Firebase Cloud Messaging (FCM) was used to send push notifications to the
Android app. When a user’s plane has been caught and thrown by someone else, a
notification showing how many cities and miles it has travelled is sent to the
device of the plane’s creator via FCM. Outgoing notifications are managed to
ensure they are not sent too frequently to a device.

Background Service

We implemented a background service to run once a day which checks against local
storage to determine when a user last visited the app. If the user hasn’t
visited in over two weeks, the app sends a notification to invite the user back
into the app to create a new plane.

The Communication Network

Our application runs on a network of servers on Google Cloud Platform. We used
built-in geocoding headers to get approximate geographic locations for stamps
and Socket.IO to connect all devices over WebSockets.

Users connect to the server nearest them, which relays messages to a single main
server as well as to any desktop computers viewing the experience in that

Moving forward

This approach worked extremely well for us, enabling an experience that was
smooth and captivating across platforms and form factors, connecting people from
all over the world. Extending the web with native capabilities has proven to be
a valuable avenue to deliver high quality experiences going forward. You can
learn even more on the Android
Experiments website.

Announcing the Project Zero Prize


Posted by Natalie Silvanovich, Exploit Enthusiast

Despite the existence of vulnerability rewards programs at Google and other companies, many unique, high-quality security bugs have been discovered as a result of hacking contests. Hoping to continue the stream of great bugs, we’ve decided to start our own contest: The Project Zero Prize.

The goal of this contest is to find a vulnerability or bug chain that achieves remote code execution on multiple Android devices knowing only the devices’ phone number and email address. Successful submissions will be eligible for the following prizes.

First Prize

$ 200,000 USD, awarded to the first winning entry.   

Second Prize

$ 100,000 USD, awarded to the second winning entry.

Third Prize

At least $ 50,000 USD awarded by Android Security Rewards, awarded to additional winning entries.

In addition, participants who submit a winning entry will be invited to write a short technical report on their entry, which will be posted on the Project Zero Blog.

Contest Structure

This contest will be structured a bit differently than other contests. Instead of saving up bugs until there’s an entire bug chain, and then submitting it to the Project Zero Prize, participants are asked to report the bugs in the Android issue tracker. They can then be used as a part of submission by the participant any time during the six month contest period. Only the first person to file a bug can use it as a part of their submission, so file early and file often! Of course, any bugs that don’t end up being used in a submission will be considered for Android Security Rewards and any other rewards program at Google they might be eligible for after the contest has ended.

In addition, unlike other contests, the public sharing of vulnerabilities and exploits submitted is paramount. Participants will submit a full description of how their exploit works with their submission, which will eventually be published on the Project Zero blog. Every vulnerability and exploit technique used in each winning submission will be made public.


So why are we doing yet another hacking contest? Our main motivation is to gain information about how these bugs and exploits work. There are often rumours of remote Android exploits, but it’s fairly rare to see one in action. We’re hoping this contest will improve the public body of knowledge on these types of exploits. Hopefully this will teach us what components these issues can exist in, how security mitigations are bypassed and other information that could help protect against these types of bugs.

Also, we’re hoping to get dangerous bugs fixed so they don’t impact users. Contests often lead to types of bugs that are less commonly reported getting fixed, so we’re hoping this contest leads to at least a few bugs being fixed in Android.

Finally, we hope that this contest will give us another data point on the availability of these types of exploits. There is fairly limited public information about this subject, and we might be able to glean some useful data from the number of submissions. Of course, a contest can never truly replicate the market conditions within which vulnerabilities are bought and sold, but it still provides at least some interesting information.  If the first prize is won in thirty seconds, we learn something. If there are no submissions, we learn something. But we’re expecting we’ll get something in between.

Interested? See the full contest rules and frequently asked questions for more information, including how to submit. The contest starts today!

Happy Hunting!

Introducing new app categories — From Art to Autos to Dating — to help users better find your apps


Posted by By Sarah Karam, Google Play Apps Business Development

With more than 1 billion active users in 190 countries around the world, Google
Play continues to be an important distribution platform for you to build a
global audience. To help you get your apps in front of more users, it’s
important to make them more quickly and easily discoverable in Google Play.
That’s why we rolled out major features, such as Search
Ads, Indie
Corner, store
listing experiments, and more, over the past year.

To improve the overall search experience, we’re introducing new app categories
and renaming a few existing ones, making them more comprehensive and relevant to
what users are looking for today.

The new categories include:

  • Art & Design
  • Auto & Vehicles
  • Beauty
  • Dating
  • Events
  • Food & Drink
  • House & Home
  • Parenting

In addition, the “Transportation” category will be renamed “Maps & Navigation,”
and the “Media & Video” category will be renamed “Video Players & Editors.”

To select a new category for your app or game

  1. Sign in to your Google Play
    Developer Console.

  2. Select an app.
  3. On the left menu, click Store Listing.
  4. Under “Categorization,” select an application type and category.
  5. Near the top of the page, click Save draft (new apps) or Submit update
    (existing apps).

Newly added categories will be available on Google Play within 60 days. If you
choose a newly added category for an app before the category is available for
users, your current app category may change. See additional details and view our
full list of categories in the Help

Between a Rock and a Hard Link


Posted by James Forshaw, File System Enthusiast

In a previous blog post I described some of the changes that Microsoft has made to the handling of symbolic links from a sandboxed process. This has an impact on the exploitation of privileged file overwrites for sandbox escapes. Windows does support another method of linking files together, Hard Links, which have some similar properties to file level symbolic links but also some downsides. Hard Links were not originally banned from a sandbox so given the right vulnerability we can still develop an exploit. Of course in some circumstances Hard Links can also be useful for exploiting some types of system level privilege escalation. This short blog post describes the pros and cons of Hard Links as an exploitation primitive and demonstrates its use in a real world vulnerability CVE-2015-4481. Also I’ll quickly show what’s changed after the MS15-115 update, which breaks the attack from a sandboxed context.

NTFS Hard Links

Hard Links, the ability to logically link a single file to multiple names on the same file system together, has been a feature of the Windows NTFS file system since it was originally designed. It was most likely added for POSIX compatibility. In Windows 2000 the CreateHardlink API was introduced to allow a program to create these links in an official way from Windows applications.

Why are hard links useful for local privilege escalation? One type of vulnerability is exploited by a file planting attack, where a privilege service tries to write to a file in a known location. The most flexible approach is to use symbolic links but creating these for single files reliably is tricky, especially now in sandboxed applications. To create file symbolic links on Windows you either need to control the entire directory to apply a Mount Point or you need to be an administrator to set a file level symbolic link. When you’re exploiting file writes to an arbitrary directory such as C:\ProgramData this is probably not achievable and if you already have administrator privileges it doesn’t really matter. So having the ability to drop a file which links to another file is a very useful primitive. If you can then get a privileged service to overwrite the target file it’ll cause corruption or in the ideal case privilege escalation.

Fortunately it looks like we don’t even need to write our own tool; since the release of Vista the command shell has an inbuilt command, MKLINK, which will create a hard link. All you need to do is pass the /H option. If we try and use this command we immediately come across a problem as shown in the following screenshot.


We can create a link to a file we already control but we can’t create a link to a file we don’t have write access to. This completely removes any utility from a local EoP perspective, if we can only overwrite files we can already write to it isn’t much of a concern. We could stop right here and give up, but where’s the fun in that. First let’s look at the actual implementation of CreateHardlink to see what privileges it’s asking for.

BOOL CreateHardLinkW(LPCWSTR lpFileName, LPCWSTR lpExistingFileName) {
 NTSTATUS status;
 OBJECT_ATTRIBUTES ObjectAttributes;  
 HANDLE FileHandle;

 if (!RtlDosPathNameToNtPathName_U(lpExistingFileName, &ntname))
   return FALSE;
 InitializeObjectAttributes(&ObjectAttributes, &ntname, …);
 status = NtOpenFile(&FileHandle, SYNCHRONIZE | FILE_WRITE_ATTRIBUTES,
                 &ObjectAttributes, …);
 if (status < 0)
   return FALSE;

 if (!RtlDosPathNameToNtPathName_U(lpFileName, &target))
   return FALSE;
 PFILE_LINK_INFORMATION LinkInfo = RtlAllocateHeap(target.Length + 16);
 memmove(LinkInfo->FileName, target.Buffer, target.Length);
 LinkInfo->ReplaceIfExisting = FALSE;
 LinkInfo->RootDirectory =  NULL;
 LinkInfo->FileNameLength = target.Length;
 status = NtSetInformationFile(FileHandle, LinkInfo,
             target.Length + 16, FileLinkInformation);
 if ( status < 0 )
   return FALSE;      
 return TRUE;

When the target file is opened the desired access is requesting FILE_WRITE_ATTRIBUTES, this kind of makes some sense, there’s a hard link count in the file’s directory entry so perhaps we need to write to the target file entry in some way? Still what would happen if we just open the file for read, would it still work? As the call to ZwSetInformationFile with the FileLinkInformation class is documented let’s just reimplement the function but not request write permissions when opening the linked to file.

Spoiler, if we try the new function it works without needing write access to the target file. This makes it much more useful. Of course if we’d just looked at the kernel implementation we’d have seen that we didn’t need any specific access rights to the file. In ZwSetInformationFile a call is made to ObReferenceObjectByHandle to get the underlying file object. This takes a desired access parameter, which turns out to be 0 for the FileLinkInformation information class. We don’t need to hold any access on the target file at all, we just need a handle to it with any assigned permissions.

Not every case of file overwrite vulnerabilities can be exploited using hard links. The Win32 and standard C library APIs don’t provide many options to prevent the attack outside of requiring that the file doesn’t already exist. The MoveFile API is secure (as long as you don’t pass the MOVEFILE_COPY_ALLOWED flag to MoveFileEx which would simulate a copy operation) as it always replaces the file entry.

So the pros and cons of Hard Links are:


  • Can create a new hard link at the file level without privileges even in sandboxes (well, originally).


  • Must have write access to the directory where the hard link will be placed, can’t just do it from a handle
  • Can only overwrite existing files which you can open for access, can’t create new files
  • Can’t redirect a MoveFile operation (except cross drive), but can redirect CopyFile.
  • Can only link to files on the same volume
  • Can’t link directories to each other

I’ve added an implementation of this technique to my Symbolic Link Testing Tools suite available in Github here.

Quick Exploit, Mozilla Maintenance Service

Let’s see this in a real world exploit; you can read up on the issue in the Project Zero bug tracker here. The vulnerability was in the Mozilla Maintenance Service, which is installed by default. This is a system service which allows Mozilla applications such as Firefox to update without needing administrator privileges. One interesting feature of this service is it can be started by any user on the system and takes command line arguments to specify the update process. This is in contrast to similar services for other products, which typically automatically update via the Internet without the user account being involved.

When an update process is started by the user application the service writes out a status log to the directory C:\ProgramData\Mozilla\logs under the name maintenanceservice.log. This is interesting as ProgramData’s default permissions allow a normal user to create new files in its subdirectories. There is a problem, however: if we look at the permissions on the logs directory (shown below), while any user can create a new file only the owner, through the CREATOR OWNER SID, gets permission to delete it. This means we can’t just delete the log file and replace it with a hard link as the owner is SYSTEM.

Log Security (1).png
Fortunately if we look at the code there’s a window of opportunity, before creating the log file a call is made to the BackupOldLogs function. This function moves each log file to a new numbered log, this ends up freeing up the initial log directory entry for a brief window of time as shown below.  

Log Rotation.png
As we can create a new file in the directory we can replace the log file directory entry with a hard link to an existing file we want to overwrite. The service will then open and write to that file entry as SYSTEM, which means we can overwrite many files on the system. While we can’t completely control the contents of the file that gets written, we can inject commands through the service’s command line (it doesn’t check for new-lines etc.). This at least gives us the ability to cause a local DoS on the system by overwriting a critical file, or we can replace certain script files such as Powershell modules, which could get executed in a privileged context and the parser doesn’t care so much about garbage in the file. Ultimately in this case the real issue was that the user could write to the log directory, and this was changed to writing logs into the service’s program files directory instead.

So What’s Changed?

I was originally going to describe this trick as a replacement for Symbolic Links inside a sandbox in my 44con presentation on Windows 10 security. Microsoft requested I send them the slides, which I did for their own interest. After reviewing them they felt the fact that this was usable from a sandboxed context effectively gets around some of the restrictions they were adding regards Symbolic Links so asked me to not present the information. While I’d publicly disclosed this technique in the Maintenance Service issue (as well as a vulnerability in Adobe Reader CVE-2015-4446) and so pointed out the information was already available I did agree to the redaction with a promise they would fix it in a security bulletin.

That bulletin, MS15-115, came out in the November patch releases and the fix is referenced as CVE-2015-6113. The fix adds the following code to the kernel’s NtSetInformationFile function.

ACCESS_MASK RequiredAccess = 0;

if (FileInformationClass == FileLinkInformation) {
 if (RtlIsSandboxedToken()) {
   RequiredAccess |= FILE_WRITE_ATTRIBUTES;

// Will return STATUS_ACCESS_DENIED if we don’t have access
ObReferenceObjectByHandle(FileHandle, RequiredAccess, …);

This mitigates the issue in sandboxed processes as it now requires FILE_WRITE_ATTRIBUTES permission on the file handle, which matches with what the CreateHardLink function expects. This would fix the vulnerability in Adobe Reader but would do nothing for the Maintenance Service vulnerability.


Hopefully this blog at least gives you an idea of how to use Hard Links on Windows. It should also give you an impression that you should never trust the documented interfaces for an operating system to behave as documented. This technique can be used to exploit local system services that try and write known files to directories the user can create files in, including things like ProgramData and the Windows Temp folder. Almost certainly there are other similar vulnerabilities that you could find.

It’s good to see MSRC again taking a practical approach to improving sandbox security by closing off known attack techniques. Keep looking for more changes that use the RtlIsSandboxedToken API as time goes on.

Android Developer Story: Culture Alley reaches millions of English learners on Google Play

anzhuo66.comPosted by Lily Sheringham, Google Play team

Alley developed the app Hello
English to help Indians learn English through gamification, supporting over
15 dialects. More than 13 million people now use Hello English in India and
around the world.

Hear Nishant Patni, Founder & CEO and Pranshu Bhandari, Co-Founder, explain how
they optimized the app to address challenges faced by emerging markets. Learn
how they used various Google Play tools to address varying levels of
connectivity and device capabilities, and improve user retention.

more best practices about building for billions and watch
the ‘10 tips to build an app for billions of users’ video to get more tips.
Also, get the
Playbook for Developers app and stay up-to-date with more features and best
practices that will help you grow a successful business on Google Play.

Protecting Android with more Linux kernel defenses


Posted by Jeff Vander Stoep, Android Security team

Android relies heavily on the Linux kernel for enforcement of its security
model. To better protect the kernel, we’ve enabled a number of mechanisms within
Android. At a high level these protections are grouped into two
categories—memory protections and attack surface reduction.

Memory protections

One of the major security features provided by the kernel is memory protection
for userspace processes in the form of address space separation. Unlike
userspace processes, the kernel’s various tasks live within one address space
and a vulnerability anywhere in the kernel can potentially impact unrelated
portions of the system’s memory. Kernel memory protections are designed to
maintain the integrity of the kernel in spite of vulnerabilities.

Mark memory as read-only/no-execute

This feature segments kernel memory into logical sections and sets restrictive
page access permissions on each section. Code is marked as read only + execute.
Data sections are marked as no-execute and further segmented into read-only and
read-write sections. This feature is enabled with config option
CONFIG_DEBUG_RODATA. It was put together by Kees Cook and is based on a subset
of Grsecurity’s KERNEXEC feature by Brad
Spengler and Qualcomm’s CONFIG_STRICT_MEMORY_RWX feature by Larry Bassel and
Laura Abbott. CONFIG_DEBUG_RODATA landed in the upstream kernel for arm/arm64
and has been backported to Android’s 3.18+ arm/arm64 common

Restrict kernel access to userspace

This feature improves protection of the kernel by preventing it from directly
accessing userspace memory. This can make a number of attacks more difficult
because attackers have significantly less control over kernel memory
that is executable, particularly with CONFIG_DEBUG_RODATA enabled. Similar
features were already in existence, the earliest being Grsecurity’s UDEREF. This
feature is enabled with config option CONFIG_CPU_SW_DOMAIN_PAN and was
implemented by Russell King for ARMv7 and backported to Android’s
4.1 kernel by Kees Cook.

Improve protection against stack buffer overflows

Much like its predecessor, stack-protector, stack-protector-strong protects
against stack
buffer overflows, but additionally provides coverage for more
array types, as the original only protected character arrays.
Stack-protector-strong was implemented by Han Shen and added to the gcc
4.9 compiler.

Attack surface reduction

Attack surface reduction attempts to expose fewer entry points to the kernel
without breaking legitimate functionality. Reducing attack surface can include
removing code, removing access to entry points, or selectively exposing

Remove default access to debug features

The kernel’s perf system provides infrastructure for performance measurement and
can be used for analyzing both the kernel and userspace applications. Perf is a
valuable tool for developers, but adds unnecessary attack surface for the vast
majority of Android users. In Android Nougat, access to perf will be blocked by
default. Developers may still access perf by enabling developer settings and
using adb to set a property: “adb shell setprop security.perf_harden 0”.

The patchset for blocking access to perf may be broken down into kernel and
userspace sections. The kernel patch is
by Ben Hutchings and is
derived from Grsecurity’s CONFIG_GRKERNSEC_PERF_HARDEN by Brad Spengler. The
userspace changes were contributed
by Daniel Micay. Thanks to Wish
Wu and others for responsibly disclosing security vulnerabilities in perf.

Restrict app access to ioctl commands

Much of Android security model is described and enforced by SELinux. The ioctl()
syscall represented a major gap in the granularity of enforcement via SELinux.
Ioctl command
whitelisting with SELinux was added as a means to provide per-command
control over the ioctl syscall by SELinux.

Most of the kernel vulnerabilities reported on Android occur in drivers and are
reached using the ioctl syscall, for example CVE-2016-0820.
Some ioctl commands are needed by third-party applications, however most are not
and access can be restricted without breaking legitimate functionality. In
Android Nougat, only a small whitelist of socket ioctl commands are available to
applications. For select devices, applications’ access to GPU ioctls has been
similarly restricted.

Require seccomp-bpf

Seccomp provides an additional sandboxing mechanism allowing a process to
restrict the syscalls and syscall arguments available using a configurable
filter. Restricting the availability of syscalls can dramatically cut down on
the exposed attack surface of the kernel. Since seccomp was first introduced on
Nexus devices in Lollipop, its availability across the Android ecosystem has
steadily improved. With Android Nougat, seccomp support is a requirement for all
devices. On Android Nougat we are using seccomp on the mediaextractor and
mediacodec processes as part of the media
hardening effort.

Ongoing efforts

There are other projects underway aimed at protecting the kernel:

  • The Kernel
    Self Protection Project is developing runtime and compiler defenses for the
    upstream kernel.

  • Further sandbox tightening and attack surface reduction with SELinux is
    ongoing in AOSP.

  • Minijail
    provides a convenient mechanism for applying many containment and sandboxing
    features offered by the kernel, including seccomp filters and namespaces.

  • Projects like kasan and kcov help fuzzers
    discover the root cause of crashes and to intelligently construct test cases
    that increase code coverage—ultimately resulting in a more efficient bug hunting

Due to these efforts and others, we expect the security of the kernel to
continue improving. As always, we appreciate feedback on our work and welcome
suggestions for how we can improve Android. Contact us at security@android.com.


lebih dari 1 juta konsumen di seluruh dunia puas dengan potenzol asli dari pada obat perangsang wanita alami buatan sendiri!
Obat Perangsang Wanita potenzol asli merupakan revolusioner solusi bagi para pasangan yang telah membantu lebih dari 1 juta pasutri untuk mengatasi masalah hubungan seksual dalam kehidupan rumah tangga,Potenzol asli secara cepat dan tepat dapat meningkatkan libido perempuan,gairah atau horny,tanpa efek samping dan tingkat keberhasilannya mencapai 95%

OBAT PERANGSANG WANITA PALING AMPUHOBAT PERANGSANG WANITA PALING AMPUH Potenzol Asli merupakan produk CARA MEMBUAT WANITA TERANGSANG SEKS terlaris di indonesia dari tahun 2012 hingga sekarang Maret Tahun 2016

Rahasia MEMBUAT WANITA TERANGSANG SEKS Anda Secara Instan Dengan Memakai Potenzol Asli

Seiring dengan perkembangan zaman, penggunaan obat perangsang wanita alami memang meningkat drastis jumlahnya. Rupanya dewasa ini mulai banyak pasangan yang menyadari bahwa peran penambah gairah wanita atau obat perangsang pria dalam hubungan seks sangat menentukan tingkat kepuasan bercinta dalam kehidupan berumah tangga.

Memang harus dimaklumi kenapa obat perangsang wanita alami sangat banyak diminati publik,Selain efeknya yang sangat cepat dan memuaskan, obat perangsang pria Potenzol juga banyak dipercaya memiliki manfaat lain, seperti meningkatkan stamina untuk bekerja dan membuat daya tahan tubuh semakin meningkat.

Kini anda tidak perlu khawatir dengan masalah hubungan seks rumah tangga anda,simak dengan cermat tentang potenzol asli obat perangsang atau penambah gairah wanita herbal.

Potenzol asli adalah pengertian dari sebuah OBAT PERANGSANG WANITA PALING AMPUH merk Potenzol yang asli bukan aspal yang berfungsi untuk meningkatkan gairah / libido wanita berkali-kali lipat sehingga wanita tersebut selalu menginginkan hubungan seksual terus menerus kepada Anda

Potenzol asli berasal dari Germany, di negara asalnya biasa dikenal dengan spelling Potenzholz (bahasa Germany), di Indonesia Potenzol dikenal juga sebagai Potenzol cair, perangsang cair, obat perangsang wanita, obat perangsang alami, obat perangsang dsb.

OBAT PERANGSANG WANITA PALING AMPUH Potenzol adalah obat perangsang wanita cair khusus wanita dewasa, formula ajaib yang terkandung merupakan obat perangsang yang alami,terbaru dan terlaris dari jerman berbentuk cair seperti air tidak berasa maupun berwarna.OBAT PERANGSANG WANITA PALING AMPUH

Kemasan produk dalam botol potenzol bisa dipakai sampai 5x penggunaan, 10-20 menit setelah minum akan langsung reaksi dan mampu bertahan selama 4 jam, setelah minum atau mengkonsumsi potenzol maka reaksi obat perangsang akan bikin cewek panas dingin menahan nafsu birahinya.

obat perangsang potenzol ini Sangat hebat daya kerjanya dalam membangkitkan libido dan mendongkrak gairah seks, wanita manapun akan dibuat takluk dalam pelukan anda dan tidak berdaya menahan nafsu birahinya yang meledak- ledak.

Potenzol cair asli merupakan satu- satunya obat perangsang wanita dewasa yang telah melalui hasil riset para pakar seks dari luar negeri yang telah melakukan penelitian sekian lama dengan metode ilmiah sehingga akhirnya menemukan sebuah formula yang tepat, dan dahsyat untuk meningkatkan libido sexsual wanita.

Wanita frigit (menopause) sekalipun akan dibuat bergairah kembali dalam tempo kurang dari 10-15 menit, Potenzol sangat cocok digunakan oleh para pasangan yang kehilangan nafsu birahinya,Setelah mengkonsumsi obat perangsang cair potenzol ini maka pasangan anda akan kembali bergairah meledak- ledak bagaikan pengantin baru lagi.

Produk cara merangsang wanita terbaik potenzol ini telah diuji dengan metode ilmiah dengan hasil keberhasilan 98,9%, sangat terkenal di jerman dan menjadi salah satu obat perangsang cair sangat terpopuler di sana serta menjadi andalan pria dewasa dalam membangkitkan gairah seks pasanganya.

obat Potenzol asli merupakan zat yang aman digunakan untuk wanita dan bereaksi sangat cepat (sekitar 5 hingga 10 menit) dan setelah zat obat perangsang wanita Potenzol bekerja maka selanjutnya terserah Anda

Seputar Tentang Kehebatan Potenzol Asli

Sejak awal kehadirannya Potenzol memiliki fakta-fakta unik sebagai berikut :

  • Potenzol asli obat perangsang wanita ini seringkali digunakan pada produksi film porno di dunia, banyak artis-artis porno wanita yang diberikan zat perangsang sejenis Potenzol sebelum shooting, sehingga saat shooting berjalan, mood wanita tersebut akan terjaga dan akan cenderung lebih aktif dan buas saat berhubungan intim dengan lawan mainnya.
  • Potenzol asli berbentuk cair dan tidak berwarna, tidak berasa, dan tidak berbau sehingga tidak akan terdeteksi saat diminum.
  • Potenzol asli aman digunakan untuk wanita dan tanpa efek samping.
  • Potenzol asli bereaksi ampuh pada wanita namun jika digunakan oleh pria maka efeknya kurang terasa, misalnya ada 1 gelas es jeruk yang telah diberikan Potenzol, lalu 1 gelas tersebut Anda minum berdua, maka yang terkena efek Potenzol adalah si wanita sedangkan Anda biasa-biasa saja.Hal ini karena hormon di dalam tubuh pria dan wanita berbeda sehingga Potenzol akan bereaksi lebih pada wanita untuk meningkatkan libido sexsnya.
  • Potenzol asli berguna untuk keharmonisan rumah tangga dan untuk meningkatkan libido sang istri yang sedang menurun atau tidak bergairah.
  • Potenzol asli bahkan dicari oleh kaum hawa/wanita yang berinisiatif untuk merangsang dirinya sendiri yang bertujuan agar lebih bersemangat dalam berhubungan seks sehingga lebih memuaskan pasangannya saat berhubungan seks.
  • Efek Potenzol asli bertahan hingga (up to) 4 jam sejak diminum, selama waktu tersebut wanita idaman Anda akan terus terangsang.
  • Potenzol asli bekerja hingga mencapai titik klimaks pada wanita, sehingga jika wanita tersebut belum mencapai klimaksnya maka wanita tersebut akan minta terus

Satu-satunya problem penggunaan Potenzol asli adalah ketika wanita terkena zat ini maka dia akan minta sex terus kepada Anda, kalau Anda tidak bisa memuaskannya maka bisa gawat!!?Maka itu persiapkan diri Anda sebelum bertempur!!!!

Cara Pemakaian Perangsang Cair Potenzol

Silahkan kocok dulu botol perangsangnya,setelah itu campurkan 1/4 botol potenzol cair asli kedalam 1 gelas minuman juice atau teh manis.

Ditoko online Produk Potenzol Palsu biasanya potenzol di campur dengan air yang bersoda,tetapi potenzol asli dari kami lebih praktis cara penggunaannya untuk diberikan kepada pasangan anda.

Karena wanita sedikit banyaknya menghindari minuman yang bersoda, seperti Coca-cola, fanta, dan spirite dll, semua itu tidak perlu repot untuk dilakukan, Cukup mencampur produk perangsang potenzol asli dari kami kedalam juice atau teh manis.

silahkan anda berikan minuman tersebut kepada pasangan yang kurang gairah atau frigid tersebut, diamkan dan biarkan obat potenzol ini bekerja selama 5-10menit.

Di campurkan ke makanan juga bisa,seperti sup atau makanan yang berkuah. Setelah itu anda akan mendapati pasangan anda jadi panas dingin tubuhnya, duduk tidak tenang dan bicara tidak konsen lagi, biasanya pasangan akan langsung memeluk anda dan mencium anda, jika sudah begitu berarti reaksi potenzol cairnya sudah bekerja dengan sangat baik.

Dan ingat…jangan pernah mencampurkan obat perangsang ini dengan air susu/ air kelapa, karena tidak akan bereaksi atau menetralkan obat perangsangnya.


  1. Meningkatkan keseimbangan Estrogen dan Progesteron.
  2. Meningkatkan gairah sexual / libido.
  3. Mencegah & mengatasi menopouse (Vagina kering & panas tiba-tiba).
  4. Mempermudah pencapaian orgasme.
  5. mengatasi prementruasi.

Catatan Penggunaan Potenzol:

  • Gunakan Potenzol dengan bijak, gunakan untuk pasangan Anda dan bukan untuk perbuatan yang melanggar hukum!
  • Jangan dicampur dengan susu atau air kelapa karena bisa pudar efek zatnya.
  • Jangan berikan pada wanita yang sedang haid karena wanita yang sedang haid memiliki fase tubuh yang berbeda.
  • Jauhkan dari anak-anak.

Efek Potenzol Cair Asli

Setelah 5 – 10 menit wanita yang meminum Potenzol akan memiliki ciri-ciri sebagai berikut :

  1. Suhu tubuh merasa tidak teratur, gerah / resah atau biasa disebut dengan “horny” atau “sange”
  2. Bicara tidak konsentrasi dan tidak fokus
  3. Duduk menjadi tidak tenang
  4. Jika Anda berada di dekat wanita tersebut maka wanita tersebut bisa langsung memeluk Anda dan selanjutnya terserah Anda.

Kunjungi Juga: Obat pembesar penis klg produk terbaru untuk memperbesar penis pria dan kesehatan seksual pria


OBAT PERANGSANG WANITA PALING AMPUHAtau Bisa Anda Kunjungi Web: ObatFrigid.Com