Start Arbitrary Activity App Components as the System User Vulnerability Affecting Samsung Android

## Overview and Background

The talk, presented by Ryan Johnson (collaborating with Angelos Stavrou and Mohamed Elsabagh from Kryptowire), addresses a privilege escalation vulnerability discovered in Samsung Android devices. Kryptowire—founded out of a 2011 DARPA project and working with agencies such as DHS S&T and NIST—specializes in software assurance, mobile device management, threat feeds, and security analytics.

The research focuses on the top layer of the Android software stack: pre-installed system applications. While Google provides the core Android framework via the Android Open Source Project (AOSP), original equipment manufacturers (OEMs) fork and customize AOSP to differentiate their devices. These vendor modifications introduce proprietary code that lacks the broad visibility of AOSP and can introduce severe security vulnerabilities. Consequently, vendors like Samsung, Huawei, Motorola, Nokia, OnePlus, and Oppo maintain independent security bulletins to patch flaws in their custom components.

## Pre-Installed System Apps and Privilege Models

Pre-installed applications are shipped natively with the device, meaning users typically cannot uninstall or even disable them. If a flaw exists in one of these applications, users must wait for an official vendor software update.

Crucially, pre-installed apps can run under specialized, high-privilege User IDs (UIDs), such as: - **System user (`uid 1000`)**: The primary target of this vulnerability research. - **Radio**: Used for telephony/phone functions, Bluetooth, Keystore, NFC, and Secure Element.

Because of their pre-installed status and privileged UIDs, these apps can obtain system permissions inaccessible to third-party applications downloaded from app stores. For instance, the `MASTER_CLEAR` permission requires a protection level of `privileged` and `signature`. A `signature` permission requires the requesting app to be signed with the exact same cryptographic key as the declaring application (in this case, the Android framework running under the system user).

## Android Component Model and Intent Messaging Architecture

Android applications are non-monolithic and lack a single execution entry point. Instead, they are composed of framework components defined within the mandatory `AndroidManifest.xml` manifest file: - **Activities**: UI components containing names, permission requirements, and intent filters. - **Services**: Background execution components. - **Broadcast Receivers**: Asynchronous event handlers. - **Content Providers**: Data management and sharing interfaces.

Inter-component and inter-process communication (IPC) is accomplished via **Intents** using **Binder** as the underlying transport mechanism. Intents function as message abstractions: - An app creates an Intent specifying an abstract action string (e.g., `CALL_PRIVILEGED`) and a data URI (such as a phone number). - The system resolves and routes the Intent to registered components that match the action filters. - Internally, Intent messages carry payloads using the `Bundle` data type, which stores key-value pairs. - Bundles support primitive types, arrays, and objects implementing the `Serializable` or `Parcelable` interfaces, where `Parcelable` provides fast serialization via explicitly implemented read/write routines.

## Scope and Methodology

The presentation outlines an investigation into intent injection vulnerabilities within Samsung's customizations, specifically enabling third-party unprivileged applications to force privileged system-level pre-installed components (running as `uid 1000`) to execute arbitrary activity components. The methodology incorporates dynamic testing to confirm exploit use cases, followed by coordinated vulnerability disclosure and analysis of impacted Android/Samsung firmware versions.