Advania UK logo  Advania UK logo compact

Samsung Dual Messenger Sandbox Escape and Privilege Escalation

Advania - Samsung dual messenger sandbox escape
Posted On
Written by
Duration of read
5  min
Share Article
Subscribe via email


A vulnerability was identified in a Samsung system app which allows external malicious applications to escape the protections of the Android sandbox and raise their privileges to that of the system (UID 1000) user.


The Android Application Sandbox is an important security mechanism that isolates different app processes and their data by assigning them a unique Linux UID. As it is implemented at the kernel level of the Android OS, this security model extends to native code and to operating system applications. All of the software above the kernel, such as operating system libraries, application framework, application runtime, and all applications, run within the Application Sandbox.

We can see this in action on a rooted Android phone by performing the ‘ls -la’ command in an applications data directory, such as /data/user/0/ (the Google Play Store app).

root@hammerhead:/data/user/0/ # ls -la

drwxrwx–x u0_a15   u0_a15            2018-05-12 00:57 app_FinskySetup

drwxrwx–x u0_a15   u0_a15            1970-12-09 06:08 app_RestoreTracker

drwxrwx–x u0_a15   u0_a15            2018-05-18 09:55 app_commerce_acquire_cache

drwxrwx–x u0_a15   u0_a15            2017-10-31 18:19 app_download_internal

drwxrwx–x u0_a15   u0_a15            2018-02-09 15:45 app_sslcache

drwxrwx–x u0_a15   u0_a15            2017-10-31 18:19 app_textures

drwxrwx–x u0_a15   u0_a15            2018-04-29 17:16 app_webview

drwxrwx–x u0_a15   u0_a15            1970-12-09 06:08 app_widgets

drwxrwx–x u0_a15   u0_a15            2018-12-31 02:16 cache

drwxrwx–x u0_a15   u0_a15            2018-12-31 02:45 code_cache

drwxrwx–x u0_a15   u0_a15            2019-03-04 11:57 databases

drwxrwx–x u0_a15   u0_a15            2019-03-04 11:54 files

lrwxrwxrwx root     root              2019-03-04 11:52 lib -> /data/app/

drwxrwx–x u0_a15   u0_a15            2018-11-20 04:43 no_backup

drwxrwx–x u0_a15   u0_a15            2019-03-04 11:57 shared_prefs

127|root@hammerhead:/data/user/0/ # id u0_a15

uid=10015(u0_a15) gid=10015(u0_a15) groups=10015(u0_a15), context=u:r:init:s0

From the listing above we see that most of the paths and files are owned by the u0_a15 user/group. The id command output shows that the UID/GID for this user and group correlates to 10015.

Android apps can share UID’s, providing they are both signed with the same certificate, thus protecting the shared functionality from unauthorised apps. Applications with a shared UID can access any data or system functionality protected with that UID.


There are a number of special reserved UIDs in Android, in particular the system user with UID 1000. This user is a member of many groups and has a high level of inherent privileges and permissions that make apps that have shared system UID a high-value target for security audits. For example, a system user can trigger an outgoing phone call without user consent, as well as open any Activity on the system, whether it is exported or not.

The Vulnerability

A vulnerable app was identified in the Samsung Dual Messenger ( system app, version

Dual Messenger (

UID: 1000


App data path: /data/user/0/

APK path: /system/app/DAAgent/DAAgent.apk

Exported resources:

6 Activities

3 Broadcast Receivers

1 Content Providers

4 Services

The vulnerability affected two exported Activities (ForwardingAcitivity and ForwardShareActivity) and essentially allowed the malicious third-party app to forward unvalidated Intents to the vulnerable Activity, which were then executed with system user level permissions. The Dual Messenger functionality (Settings > Advanced Features > Dual Messenger) must be enabled on at least one app to trigger the issue.

As this activity is exported in the application manifest it can be started by any third-party application. Once the activity is started, the onCreate() method is called (as the usual entry point to Activities), and the incoming malicious Intent is validated to ensure it is not null. No attempts are made to validate the source or authenticity of the incoming Intent.

The integer UID of the profile owner is retrieved by the DAUtility.getDualAppProfileId() method, which equates to system if the Dual Messenger feature is enabled on the device, and an invalid UID if it is not. Hence the functionality must be enabled for at least one app.

The call to startActivityAsUser() with the system UID starts the malicious Intent under the context of the system user, leading to privilege escalation and access to great deal of privileged actions that could be performed by the system app, on behalf of the low privileged third-party app.

Confused Deputy?

Using a third-party low-privileged malicious app, to interact with and abuse the exported IPC components (Activities, Broadcast Receivers, Content Providers and Services) of the target system UID app, is a type of privilege escalation attack dubbed the ‘Confused Deputy’. The deputy in this case is the vulnerable system app, and it has been abused to trigger arbitrary malicious Intents with the permissions of the system user.


To exploit the vulnerability, a malicious Intent must be formed with the appropriate parameters and started from a third-party client app.

It was also possible to leverage the elevated permissions to install arbitrary APK files without user consent, by targeting an activity in the internal Android package installer.


Samsung fixed this issue, but strangely didn’t increment the version number of the system app.

Sign up to receive insights from our experts

Get the latest news and developments from Advania delivered to your inbox

Other blog articles that might interest you

Driven by client success

We’re proud to work with the some of the most ambitious and innovative organisations.


Sign up to receive insights from our experts

Get the latest news and developments from Advania delivered to your inbox.