TLDR
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.
Background
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/com.android.vending (the Google Play Store app).
root@hammerhead:/data/user/0/com.android.vending # 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/com.android.vending-2/lib/arm
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/com.android.vending # 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.
System
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 (com.samsung.android.da.daagent) system app, version 2.0.00.0.
Dual Messenger (com.samsung.android.da.daagent)
UID: 1000
Version: 2.0.00.0
App data path: /data/user/0/com.samsung.android.da.daagent
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.
Exploit
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.
Fix
Samsung fixed this issue, but strangely didn’t increment the version number of the system app.
