Android Attacks in a Nutshell (Part I)

1.1 Android and Dalvik

Android is an OS designed for smartphones. It includes a sandbox application execution environment, and a customized embedded Linux system that interacts with the phone hardware and an off-processor cellular radio. The Binder and application API runs on top of Linux. Each application is executed within a Dalvik Virtual Machine (DVM).

Applications interact with each other and the phone through different forms of IPC. Intents are typed interprocess messages that are directed to particular applications or systems services, or broadcast to applications subscribing to a particular intent type. Persistent content provider data stores are queried through SQL-like interfaces. Background services provide RPC and callback interfaces that applications use to trigger actions or access data. Finally, user interface activities receive named action signals from the system and other applications. DVM runs .dex files that are designed to be more compact and memory-efficient than Java class files. DVM fucntions close to Java Virtual Machine (JVM), with differences in application structure, register architecture, instruction set, constant pool structure, ambigous primitive types, null reference and comparison of object references. [4]

Figure 1: The Android System Architecture [4]

1.2 Android Security Mechanism
Shabtai et. al [2] categorizes Android’s security mechanisms into three main categories:
 • Linux Mechanism
 • POSIX users
 • File Access
 • Environment features
 • Memory management unit (MMU)
 • Type safety
 • Mobile carrier security features
 • Android-specific mechanisms
 • Application permissions
 • Component encapsulation
 • Signing applications
 • Dalvik virtual machine

One of the most crucial elements inside the previously mentioned list is the application permission mechanism. Generally, Android permissions are categorized into 3 security levels: Normal, Dangerous, and Signature. Normal permissions protect API calls that could annoy but not harm the user (e.g., SET_WALLPAPER); these do not require user approval. Dangerous permissions let an application perform harmful actions (e.g., RECORD_AUDIO). Signature permissions regulate access to extremely dangerous privileges, e.g., CLEAR_APP_USER_DATA.

 Depending on which OS functionalities an application wants to access, the developer has to define the permissions that his application requires. All permissions an applications needs are specified in the AndroidManifest.xml file, which is part of the every application package. Typical permissions comprise e.g. android.permission.INTERNET permission, which allows applications to open network connections. The permissions that were defined by the developer are shown to the user during the installation process of the application. Upon seeing them, the user can either decide to install the application and grant it all requested permissions, or he can abort the installation process. Permissions can neither be granted individually nor can they be granted or revoked at runtime. This process is also called install time permission grant system, which is the opposite of Time-of-Use permission systems as in Apple iOS. The user either accepts all requested permissions, or he cannot install the application. 

In this report two attacks are presented. First is a Cross-Site Scripting (XSS) attack against WebKit Web engine. The attack is classfied under minor-impact attacks with high rate of occurance. Seocond attack is a permission re-delegation which is an intersect of taxanomies 4 and 6, each of which have severe-impact with medium and high rate of occurance, reprectively. For more details on security factors in Android, see [2].