Android Security

Architecture I
Dr.-Ing. Sven Bugiel

Mobile Security | WS24/25 | 2024-10-18

 Recap last lecture

• Android apps consist of several components (Activities, Services, etc.)

• Components are registered in the system through the application
Manifest.xml
− BroadcastReceivers need to be registered at runtime with a few
exceptions for explicit Broadcasts targeting the application
• Primary channel for Inter-Component-Communication are Intents
− Intents are an indirect communication that is relayed via the
ActivityManagerService
− Explicit target component or implicit via attributes (Action string,
category, mime type, etc)
− Bound services and ContentProviders can also be contacted directly after
receiving a reference from the Android system
• Since Android 11: Restrictions on package visibility

2
Secure
Architecture
Principles
Basic Notions
 General Security Objectives

• What do we want to achieve in computer security?

− Confidentiality: Ensuring that information is not accessed by
unauthorized persons (e.g., access control or encryption)
− Integrity: Ensuring that information is not altered by unauthorized
persons in a way that is not detectable by authorized users (e.g., access
control or checksums)
− Availability: Ensuring timely and reliable access to and use of
information and preventing unauthorized withholding of information.
− Authenticity: Ensuring that users are the persons they claim to be.
− Authorization: What information is an authenticated user allowed to
access or which operations allowed to perform
− Different other objectives:
− Non-repudiation, accountability, anonymity, unlinkability,…

4
 Important security objectives in mobile context
• Privacy
− Confidentiality and integrity of personal data
− Easy? User wants to share some data, while protecting other data (=subjective
decisions)
− “Contextual integrity” by Helen Nissenbaum:
Parameters for CI = <data subject, sender of data, recipient of data, information type,
transmission principle>
• Integrity of system
− “Trusted computing base”: Software (and hardware) of a system responsible for enforcing
security policies
− TCB must be of integrity to enforce policies
• Integrity of applications’ code and data
− Applications and their data should not be compromised by other applications
• Confidentiality of applications’ data
• Authenticity of applications
• Others: Secure network connections,…

5
Example:
Package Integrity
and Authenticity
 Package signing

• All major mobile platforms use signed application packages

− Integrity of packages
− Some: Authenticity of packages
− For example: Central authority vouches for developer identity in
certificate

• Who signs the packages?

− Android: App developer (and Google Play)
− iOS: Market (“walled garden”)
− Tizen: Multiple signing authorities (Manufacturer & network operator)
− Symbian: App developer / Market for highly privileged apps

7
 Android package signature schemes

• Package signing on Android has evolved with different Android versions:

− Android ≤6.0: Signature scheme v1
− Android 7.0: Signature scheme v2 added
− Android 9.0: Signature scheme v3 added
− Android 11.0: Signature scheme v4 added

Backwards
compatible

8 https://source.android.com/security/images/apk-validation-process-v4.png
 Recap: Application packages (APK)

• APK is simply a packaging format like JAR, ZIP, or TAR

• Components of applications
− Activity: User interface
− Service: Background service Classes.dex Native libs Resources META-INF Application
− Content Provider: SQL-like database Manifest

− Broadcast receiver: Mailbox for broadcasted messages

APK
• Applications can contain native code (C/C++ shared libraries) and resources
(e.g., images)
− Native code provided as shared library files that can be dynamically linked into
the process
− Resources and assets: String values, layout definitions, drawables (pictures), raw
data
• META-INF contains the application certificate and package manifest
− Package manifest not to be mistaken with the application manifest !

9
 Signature scheme v1 (JAR signing)
• Created with jarsigner or apksigner
• META-INF/
− Manifest.mf: List of files in the packages and their hash value
− <signer>.SF: List of resources and their signature value
− <signer>.{RSA,DSA,EC}: Certificate of the application (PKCS#7) and signature of the <signer>.SF file
− One pair per signing party

File Manifest.mf <signer>.SF

Manifest-Version: 1.0 Manifest-Version: 1.0

Created-By: 1.0 (Android) Created-By: 1.0 (Android)
SHA1-Digest-Manifest: f69XkdZ0/GvvTRhrLZ0tL7Q/zYw=
Hash Name: res/drawable-xhdpi/ic_launcher.png Hash
SHA1-Digest: AfPh3OJoypH966MludSW6f1RHg4= Name: res/drawable-xhdpi/ic_launcher.png
SHA1-Digest: cIga++hy5wqjHl9IHSfbg8tqCug=
ic_launcher.png Name: res/drawable-hdpi/ic_launcher.png
SHA1-Digest: Nq8q3HeTluE5JNCBpVvNy3BXtJI= Name: res/drawable-hdpi/ic_launcher.png
SHA1-Digest: stS7pUucSY0GgAVoESyO3Y7SanU=
…

Certificate <signer>.SF signature

<signer>.{DSA,RSA,EC}
(PKCS #7 CMS ContentInfo with SignedData structure)

10 http://www.manpagez.com/man/1/jarsigner/
 Example reading the certificate

• APK is simply a packaging format like JAR, ZIP, or TAR

11
 Example reading the certificate
$ openssl pkcs7 -print_certs -inform DER -text -in BUBBLEWI.RSA

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1326376807 (0x4f0ee767)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=RO, ST=Romania, L=Bucharest, O=king.com, OU=Mobile, CN=Cristian Bidea
Validity
Not Before: Jan 12 14:00:07 2012 GMT
Not After : May 30 14:00:07 2039 GMT
Subject: C=RO, ST=Romania, L=Bucharest, O=king.com, OU=Mobile, CN=Cristian Bidea
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:9d:48:8c:64:ae:53:7e:7c:6a:1a:f0:f3:cb:a0:
--snip--
a9:86:df:65:17:9c:09:d4:99:2e:24:09:ec:16:fe:
83:4d
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
7a:6d:d5:cc:78:6f:47:6b:62:9e:0e:9d:f0:2d:e6:68:9b:df:
--snip--
fc:7e:ff:c2:df:e8:e2:c6:6f:77:33:a0:da:4d:02:fb:72:0e:
8c:a2:50:1b
-----BEGIN CERTIFICATE-----
MIIDXDCCAkSgAwIBAgIETw7nZzANBgkqhkiG9w0BAQUFADBwMQswCQYDVQQGEwJSTzE
--snip--
v4VpENyOn0ImxcvBxCGDVd5l/awc5lY6nsAcY2nd4vseB6YEfhn8fv/C3+jixm93M6DaTQL7cg6MolAb
-----END CERTIFICATE-----

12
 Example

$ cat MANIFEST.MF
Manifest-Version: 1.0
Created-By: 1.7.0_79 (Oracle Corporation)

Name: assets/res_output/levels/episode1233level3.txt
SHA1-Digest: uAgD/mKODBlLOIixDSd/deYOazs=

Name: assets/res_output/scenes/minishop/products/CandyMobileTencentSwedishFishPreGameEighteenCase2.xml
SHA1-Digest: J33CBVjTEOiDrvszXZ6DFn+Cng4=

Name: assets/res_output/shaders/uniformcolor.frag
SHA1-Digest: /hNps6PThR2g6FqSfuUqsu2x8pM=

Name: res/drawable/com_facebook_picker_list_longpressed.9.png
SHA1-Digest: /uU9+qqC9MjC0cwR3L+DskCy9xM=

Name: assets/res_output/scenes/conveyor_belt/down_to_right.xml
SHA1-Digest: aRcaTOzrRIbv1ASVmaUCXfhEouc=

Name: assets/res_output/tex/frog_grey.png
SHA1-Digest: YbBjHNd2Vy5Ls0tVMh0MhKFGqfQ=

--snip--

13
 Example
$ cat BUBBLEWI.SF
Signature-Version: 1.0
SHA1-Digest-Manifest-Main-Attributes: x/m11ArtWWwg5I8p/wTD6UcKPdw=
Created-By: 1.7.0_79 (Oracle Corporation)
SHA1-Digest-Manifest: Mz7zDcEcRNkX0Vy34AE1/tSzQcA=

Name: assets/res_output/levels/episode1233level3.txt
SHA1-Digest: iBt3dPLBS4JbTjTx9pPk55vp0H0=

Name: assets/res_output/scenes/minishop/products/CandyMobileTencentSwedishFishPreGameEighteenCase2.xml
SHA1-Digest: x5qUIGs++x9nGl7ThbIpl/uiDnY=

Name: assets/res_output/shaders/uniformcolor.frag
SHA1-Digest: 5Eo8zgVaGcjIcseEfgGn8jn0C3U=

Name: res/drawable/com_facebook_picker_list_longpressed.9.png
SHA1-Digest: 2CGPL/jp5oPTQ2ltrIIWxbJ07UM=

Name: assets/res_output/scenes/conveyor_belt/down_to_right.xml
SHA1-Digest: FTVmxWzMVeExA0k5umb36rIOscs=

Name: assets/res_output/tex/frog_grey.png
SHA1-Digest: 5gL+KK2HiskUK0B2NeYEQhGAbn0=

Name: assets/res_output/sound/sounds/sugar_drops_spawn.ogg
SHA1-Digest: IhKwApDYfWf7hSeRrynQqV/ZJQc=

--snip--

14
 Verifying of package manifest

1. Verify the certificate

2. Verify signature of <signer>.sf using the public key from the certificate
in <signer>.{DSA,RSA,EC}
3. Verify entries in <signer>.sf match the corresponding sections in the
Manifest.mf
4. For each file listed in the Manifest.mf check that its computed hash
corresponds to the hash value of the entry

Chain-of-Trust:
<signer>.{DSA,RSA,EC} ➔ <signer>.sf ➔ Manifest.mf ➔ Files

15
 Benefits

• Integrity check
− Chain-of-trust ensures that the APK content has not been modified since
the developer created and signed the APK

16
 APK Signing error a.k.a. “master key vulnerability”
(fixed now)
• Recap: Package signing
File Manifest.mf <signer>.sf
Manifest-Version: 1.0 Manifest-Version: 1.0
Created-By: 1.0 (Android) Created-By: 1.0 (Android)
SHA1-Digest-Manifest: f69XkdZ0/GvvTRhrLZ0tL7Q/zYw=
Hash Name: res/drawable-xhdpi/ic_launcher.png Hash
SHA1-Digest: AfPh3OJoypH966MludSW6f1RHg4= Name: res/drawable-xhdpi/ic_launcher.png
SHA1-Digest: cIga++hy5wqjHl9IHSfbg8tqCug=
ic_launcher.png Name: res/drawable-hdpi/ic_launcher.png
SHA1-Digest: Nq8q3HeTluE5JNCBpVvNy3BXtJI= Name: res/drawable-hdpi/ic_launcher.png
SHA1-Digest: stS7pUucSY0GgAVoESyO3Y7SanU=
…

• Container allows entries with identical name

File Manifest.mf <signer>.sf

Manifest-Version: 1.0 Manifest-Version: 1.0
Created-By: 1.0 (Android) Created-By: 1.0 (Android)
SHA1-Digest-Manifest: f69XkdZ0/GvvTRhrLZ0tL7Q/zYw=
Hash Name: res/drawable-xhdpi/ic_launcher.png Hash
SHA1-Digest: AfPh3OJoypH966MludSW6f1RHg4= Name: res/drawable-xhdpi/ic_launcher.png
SHA1-Digest: cIga++hy5wqjHl9IHSfbg8tqCug=
ic_launcher.png Name: res/drawable-xhdpi/ic_launcher.png
SHA1-Digest: abcd3HeTluE5JN1212vNy3BXtJI= Name: res/drawable-hdpi/ic_launcher.png
SHA1-Digest: stS7pUucSY0GgAVoESyO3Y7SanU=
…

ic_launcher.png
17
 APK Signing error a.k.a. “master key vulnerability”
(fixed now)
• Vulnerability:
− Android verified the first file with identical name
− Android installed and used the second file
− Technical root cause: One library for verification, one for installation
• Allows attacker to append malicious files to APK, which are used and
installed instead of verified original!

File Manifest.mf <signer>.sf

Manifest-Version: 1.0 Manifest-Version: 1.0

Created-By: 1.0 (Android) Created-By: 1.0 (Android)
SHA1-Digest-Manifest: f69XkdZ0/GvvTRhrLZ0tL7Q/zYw=
Hash Name: res/drawable-xhdpi/ic_launcher.png Hash
SHA1-Digest: AfPh3OJoypH966MludSW6f1RHg4= Name: res/drawable-xhdpi/ic_launcher.png
SHA1-Digest: cIga++hy5wqjHl9IHSfbg8tqCug=
ic_launcher.png Name: res/drawable-xdpi/ic_launcher.png
SHA1-Digest: abcd3HeTluE5JN1212vNy3BXtJI= Name: res/drawable-hdpi/ic_launcher.png
SHA1-Digest: stS7pUucSY0GgAVoESyO3Y7SanU=
…

ic_launcher.png

Install
18
 APK Signature Scheme v2

• Two-level Merkle hash tree Top-level digest

Signature(s) of top-level digest

− Harder to modify the protected content (e.g., add files)
− Signing block: signed data (digests), min/max SDK, signatures, public key
certificate
− Applied with apksigner tool, e.g., via Android Studio or on command line

19
 Benefits (cont.)

• Integrity check
− Chain-of-trust ensures that the APK content has not been modified since
the developer created and signed the APK
• “Same origin policy”
− Updates of applications only allowed when update is signed with the
same developer key

20
 Signature scheme v3 and v4

• Scheme v3 is same format as scheme v2

− Add key rotation through additional information “proof-of-rotation” in the
signing block
− Single linked list of certificates used to sign previous versions of the app
− Oldest certificate is root node in list
− Every certificate is signed with predecessor certificate in list
− Certificate can be marked as self-trusted to be used for signature
permissions
− Signature permission: next week’s lecture
• Scheme v4 follows fs-verity and adds streaming-compatible signing scheme (for
incremental updates)
− requires a complementary v2 or v3 signature; v4 signature stored separate
<apk name>.apk.idsig

21
 App bundles

• App Bundle (.aab) is the new, official publishing format (by Google)
− Bundles contains all code and resources, organized in modules
− Defers the APK generation and signing to Play
− Upload authenticated with a separate Upload Key
− Optional: developer can still be in charge of generation and signing
− Play decides which APK to generate for each user/platform
− Split APKs: Treat multiple APKs as one app (Base APK, Configuration
APKs, Feature module APKs)

https://developer.android.com/guide/app-bundle
22 https://developer.android.com/platform/technology/app-bundle
https://developer.android.com/studio/publish/app-signing
 Benefits (cont.)

• Integrity check
− Chain-of-trust ensures that the APK content has not been modified since
the developer created and signed the APK
• “Same origin policy” (SOP)
− Updates of applications only allowed when update is signed with the
same developer key
− But: Google encourages self-signed certificates
− Authenticity of developer not ensured! No PKI to validate
developer certificate!
− “Trust on first install” when installing an app (not updating) the user
must be sure to have the “right” APK

23
 Repackaging [9,10]

• APK is simply an archive file format

− Unzip, modify content, re-zip
− Easy to make an application malicious (trojan, virus, change advertisement
IDs)
• Why is repackaging possible?
− Technically easy to remove (“strip”) the original signature and re-sign the re-
packaged APK with a new certificate
− Certificates are self-signed (easy); and everybody can be a developer on the
Android market and be able to sign apps for publication (still easy)
• Does not allow malicious updates (due to SOP), but breaks trust-on-first-install
• Repackaging one of the major attack vectors on alternative markets
− Distribute malware
− Siphon ad revenue from legitimate/original developers

24
 Prevalence of cloned apps [162]

• Already in 2013: Study of 610k free apps

• Determine Jaccard index for resource names and asset signatures
− 158,204 free duplicative applications (roughly 25% of the free application
content analysed)
− 5% false positive rate in detection
− 115,896 were rebranded (i.e., same signing key) and 42,308 were clones
− Sources of cloning included: use of automated tools and wizard
services, copying open-source apps, contracting the same third-party
developer, and apparent plagiarism

25
 Impact of Android Application Plagiarism [11]

• Investigation HTTP advertising traffic generated by mobile applications at a tier-1

US cellular carrier for 12 days in 2012
− Analysis of 265,359 free applications from 17 Android markets around the
world
− Detect “clones” of apps: 5,431 clone clusters consisting of 44,268 unique
applications
− Be able to identify original apps’ and their clones’ traffic in the captured
traces (admob ids, strings, etc)

Lost revenue calculated to be between 10–50%!

26
 Google’s SafetyNet Attestation API (deprecated)

• Anti-abuse API that allows app developers to assess the Android device their
app is running on
− Reports package name and hash → server can deny service to wrong app
Nonce, Platform config, App meta-data Nonce Nonce
SafetyNet Server SafetyNet API App App Server
S = Signed(Nonce, Platform config, App meta-data) S S
Can decide if
correct app on a
trusted platform

27 https://developer.android.com/training/safetynet/attestation
 Google Play Integrity API

https://developer.android.com/privacy-and-security/safetynet

https://developer.android.com/google/play/integrity

28
Secure
Architecture
Principles
Isolation & Least Privilege
 Fundamental security design principles

• Perfectly secure does not exist (yet)

• But: Fundamental design principles to guide development of protection
mechanisms

• Secure, fail-safe defaults: System should go into a secure state in the event
of a failure. For example, allow-listing instead of deny-listing. Errors in
configuration do not directly result in access to an asset.
• Complete mediation: Every access to an asset must be checked against the
security policy.
• Open design: Design should be open to scrutiny. Security of a system should
not depend on the secrecy of its protection mechanism. See also Kerckhoffs'
principle of cryptography.

30
 Fundamental security design principles (cont.)

• Perfectly secure does not exist (yet)

• But: Fundamental design principles to guide development of protection
mechanisms

• Separation of privilege: Multiple privilege attributes are required to achieve

access to a restricted resource. For example, multi-factor authentication or
splitting SSH daemon.
• Least privilege: Every process and every user of the system should operate
using the least set of privileges necessary to perform their tasks. Compromise
only yields minimum set of privileges.
• Least common mechanism: Minimize the functions shared by different users,
providing mutual security.
• Minimum exposure: Minimize the attack surface a system presents to the
adversary.

31
 Fundamental security design principles (cont.)

• Perfectly secure does not exist (yet)

• But: Fundamental design principles to guide development of protection mechanisms

• Isolation: Isolate critical resources physically or logically. Isolate data and process from
different users. Isolate protection mechanisms to avoid tampering with them.
− Encapsulation: Object-oriented form of isolation. For example: encapsulate data
objects in domain of its own such that internal structure only accessible through
procedures of the protected system and those procedures may only be called via
designated entry points.
• Modularity / Compartmentalization: Modular system architecture and security
mechanisms as isolated, protected modules. Helps protecting individual modules from
tampering.
• Defense-in-depth: Use multiple, overlapping protection approaches, the failure or
circumvention of any individual protection approach will not leave the system
unprotected. No single point of failure.

32
 Fundamental security design principles (cont.)

• Perfectly secure does not exist (yet)

• But: Fundamental design principles to guide development of protection
mechanisms

• Minimize Trust and maximize Trustworthiness: Trust is an assumption that

the system behaves as expected and should be avoided whenever possible.
Trustworthy systems satisfy this expectation, i.e., turn assumptions into
validated properties (e.g., proof).
• Acceptance by users: AviD’s rule: “Security at the expense of usability
comes at the expense of security.” Users actively work against protection
mechanisms that hinder them in their tasks. Security procedures must
reflect the user’s mental model of protection to minimize the risk of human
errors.

33
 Principles of Secure Design in Android

Right now, we look at:

• Compartmentalization
• Isolation
• Principle of least privilege

34
 Monolithic design

Network Network

User input User device

System
File system File system

35
 Monolithic design

Network Network

User input User device

System
File system File system

36
 Monolithic design

Network Network

User input User device

System
File system File system

37
 Component design

Network Network

User input User display

File system File system

38
 Component design

Network Network

User input User display

File system File system

39
 Component design

Network Network

User input User display

File system File system

Compartmentalization possible at different levels:
• Split software into modules (e.g., SSH daemon)
• OS mechanisms (chroot, UIDs, containers, …)
• Micro-Kernel
• Virtual machines

40
 Principle of Least Privilege

• What is a ‘privilege’?
− Ability to access or modify a resource (e.g., file, hardware, networking)
− Privileged process: Process that has access to some resource not generally available
− More secure systems have many types of privilege
• Assume compartmentalization and isolation
− Separate the system into independent modules
− Limit interaction between modules

Principle of least privilege:

A system module should only have the minimal privileges required for its
intended purposes

• Obvious reason: A malicious or compromised process cannot misuse privileges that it

does not have!

41
 Abstract example

• In comparison: Monolithic design complicates least privilege

− Attacker gains all privileges

Network Network

User input User display

File system File system

• Compartmentalization helps with realizing least privilege

− Attacker gains only “network” privilege in the compromised
module
Network Network

User input User device

System
File system File system

42
Android Security
Architecture
Sandboxing
 Sandboxing

General Idea

The application sandbox specifies which system

resources the application is allowed to access.
An attacker can only perform actions defined in the
sandbox.

44
 Application Isolation by Sandboxing

• Each application is isolated in its own sandbox

− Applications can access only its own resources
− Access to sensitive resources depends on the application’s rights
• Sandboxing is enforced by Linux
− Each App is assigned a unique UID during installation and runs in separate process
− Each App has a private data folder
No rights for
“Internet”!

45
 Process Tree on Linux

46
 Process Tree on Android

47
 Application Process Internals

App Process
Dalvik VM / ART
App Code
(Classes.dex)

JNI
Native code
Core libs (*.so)

syscalls
Kernel
JNI = Java Native Interface

48
 Application Sandbox

• DVM/ART is not a security boundary!

− Could be easily circumvented with native code

App Process
Dalvik VM / ART
App Code
(Classes.dex)

JNI
Native code
Core libs (*.so)

syscalls
Kernel
49
 Application Sandbox

• Isolation: Android enforces isolation at the UID A

process level and relies on the underlying Linux
kernel
• Every installed app has a separate user ID (UID)
(per user since Android 5.0) and group ID (GID)
− Each app lives in its own sandbox

Process boundary Process boundary

UID A UID B UID C

Kernel
50
 Multi-process Apps and Shared UIDs
(Deprecated since Android 10)
▪ Apps might consist of multiple processes (e.g., process attribute in manifest)

▪ Multiple applications can share their UID, i.e., their sandbox

▪ Shared UIDs only allowed for applications signed with same developer key

Process boundary Process boundary

UID A UID A UID C

Kernel
51
 Back to component design

Application
Framework

Linux Kernel

Binder IPC, Inter-Component Communication, Files, …

52
 High-level view: Starting new application process

Zygote DVM / ART

(UID A)
(root)
2) Load
App Code
APK

Core libs Core libs

1) Fork() 3) setUID(A)
4) Give control flow to
VM process
53
 Process Tree on Android

54
 Predefined UIDs

• Application UIDs > 10,000

• Predefined UIDs for core Android apps and services
$(Android_root_folder)/system/core/libcutils/include/private/android_filesystem_config.h

#define AID_ROOT 0 /* traditional unix root user */

/* The following are for LTP and should only be used for testing */
#define AID_DAEMON 1 /* traditional unix daemon owner */
#define AID_BIN 2 /* traditional unix binaries owner */
#define AID_SYSTEM 1000 /* system server */
#define AID_RADIO 1001 /* telephony subsystem, RIL */
#define AID_BLUETOOTH 1002 /* bluetooth subsystem */
#define AID_GRAPHICS 1003 /* graphics devices */
#define AID_INPUT 1004 /* input devices */
#define AID_AUDIO 1005 /* audio devices */
#define AID_CAMERA 1006 /* camera devices */
#define AID_LOG 1007 /* log devices */
#define AID_COMPASS 1008 /* compass device */
#define AID_MOUNT 1009 /* mountd socket */
#define AID_WIFI 1010 /* wifi subsystem */
#define AID_ADB 1011 /* android debug bridge (adbd) */
#define AID_INSTALL 1012 /* group for installing packages */
#define AID_MEDIA 1013 /* mediaserver process */
#define AID_DHCP 1014 /* dhcp client */
#define AID_SDCARD_RW 1015 /* external storage write access */
#define AID_VPN 1016 /* vpn system */
#define AID_KEYSTORE 1017 /* keystore subsystem */
#define AID_USB 1018 /* USB devices */
...

https://cs.android.com/android
55
 Attacks: Zimperlich root exploit (fixed now)

• Zygote did not check return value of setUID call (step 3)

− Attacker can deliberately cause this step to fail (e.g., exhaust process limit
for UID A)
− New application process continues executing with root privileges!
− Root inherits all permissions in the system!

Zygote Dalvik VM
(root) RootA)
(UID
2) Load
App Code
APK
Core libs Core libs

1) Fork() 3) setUID(A)
4) Give control flow to
VM process
56
https://thesnkchrmr.wordpress.com/2011/03/24/rageagainstthecage/
 Attacks: Breaking ASLR [110]

• ASLR: Adress-space Layout Randomization (counter- DVM / ART

(Browser)
measure against ROP attacks)
App Code
Fork()
Core libs DVM / ART
• All apps fork from Zygote (AM)

App Code

DVM / ART Core libs

• If no re-randomization of memory layout: (App A)

All apps share same memory locations of shared App Code

libraries (core libs)
Core libs

• If attacker knows discloses the memory of one app, he

knows the layout of all apps:
Can craft exploits to circumvent ASLR!
− Malicious app installed
− Remote disclosure attacks (e.g., bug in browser)

57
 Private app directory

• Uses Linux’ discretionary file access control File type

• Permissions pre-set by system
− Read, Write, Execute - rwx rwx rwx
− Represented by vector of owner group other
four octal values
− 0o4: Read, 0o2: Write, 0o1: Execute
− E.g.: 754 = (RWX, RX, R)
• Discretionary: owner can change permissions or even the ownership
• Only owner and root can change permissions
− This privilege cannot be delegated or shared
▪ Since Android 4.3: SELinux mandatory access control in addition to
discretionary access control (→ later lecture)

58
 Private app directory

59
 Predefined file access rights
$(Android_root_folder)/system/core/libcutils/fs_config.cpp
// Rules for directories.
// These rules are applied based on "first match", so they
// should start with the most specific path and work their
// way up to the root.
static const struct fs_path_config android_dirs[] = {
// clang-format off
{ 00770, AID_SYSTEM, AID_CACHE, 0, "cache" },
{ 00555, AID_ROOT, AID_ROOT, 0, "config" },
{ 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/app" },
{ 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/app-private" },
{ 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/app-ephemeral" },
{ 00771, AID_ROOT, AID_ROOT, 0, "data/dalvik-cache" },
{ 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/data" },
{ 00771, AID_SHELL, AID_SHELL, 0, "data/local/tmp" },
{ 00771, AID_SHELL, AID_SHELL, 0, "data/local" },

--snip--

static const struct fs_path_config android_files[] = {

// clang-format off
{ 00644, AID_SYSTEM, AID_SYSTEM, 0, "data/app/*" },
{ 00644, AID_SYSTEM, AID_SYSTEM, 0, "data/app-ephemeral/*" },
{ 00644, AID_SYSTEM, AID_SYSTEM, 0, "data/app-private/*" },
{ 00644, AID_APP, AID_APP, 0, "data/data/*" },
{ 00644, AID_MEDIA_RW, AID_MEDIA_RW, 0, "data/media/*" },
{ 00640, AID_ROOT, AID_SHELL, 0, "data/nativetest/tests.txt" },
{ 00640, AID_ROOT, AID_SHELL, 0, "data/nativetest64/tests.txt" },
{ 00750, AID_ROOT, AID_SHELL, 0, "data/nativetest/*" },
--snip--

https://cs.android.com/android
60
 Selected Data Storage Options for apps

• Shared preferences
− Persistent key-value store across app restarts
− Supports MODE_PRIVATE: Data file will be saved readable only for the owning
app (default option)
SharedPreferences settings = getSharedPreferences(PREFS_NAME, Context.MODE_PRIVATE);
• Internal Storage
− Write files to the private app directory
− No need to know the absolute paths, use flags
FileOutputStream fos = openFileOutput(FILENAME, Context.MODE_PRIVATE);
• External storage
− Since Android v10/v11: Scoped storage: public abstract File getExternalFilesDir (String type)
− But: No privacy against apps with WRITE_EXTERNAL_STORAGE permission or a
granular read permission (e.g., READ_MEDIA_IMAGES)

https://developer.android.com/guide/topics/data
https://developer.android.com/reference/android/content/SharedPreferences
61 https://developer.android.com/about/versions/11/privacy/storage