Backgound: android security mechanism and threats

Android software stack

Android dominates smartphone operating systems market nearly 85% of the market share in the second quarter of 2014 (IDC, 2014). Android is an open-source software stack for a wide range of smartphone systems and tablets. It incorporates an operating system, middleware, and key applications. . The top layer is the application layer for implementing native and third-party applications, such as phone application, internet browser and media player application.

Android applications directly interact with classes of the application framework layer. These classes manage the basic functions of smartphone system. The most important classes are: (i) Activity manager manages the activity life cycle of applications, (ii) Content providers manage the data sharing between applications, (ii) Telephone manager manages all voice calls, (iv) Location manager manages locations and (v) Resource manager manages various types of resources (source.android.com, 2014; Gandhewar and Sheikh, 2010; Song et al., 2010; Shabtai et al., 2009a).

The next layer in Android software stack is native libraries. All libraries are written in C/C++, and they enable the smartphone system to handle various types of data. For instance, playback and recording different video and audio formats are supported by media framework library, Libc supports system C libraries, SGL and OpenGL are graphics library to support 2D and 3D graphics, and SQLite is a database engine (source.android.com, 2014; Gandhewar and Sheikh, 2010; Song et al., 2010; Shabtai et al., 2009a).

Android runtime layer is located on the same level as the libraries layer. It includes core libraries and Dalvik virtual machine. Core libraries provide most functions of java libraries and additional Android specific functions. Dalvik VM is a register based virtual machine optimized to execute applications of (.dex) format on limited resources devices. The Dalvik VM relies on Linux kernel for underlying functionalities, such as threading and low-level memory management (source.android.com, 2014; Gandhewar and Sheikh, 2010; Song et al., 2010; Shabtai et al., 2009a).

Android is based on Linux kernel version 2.6. Linux kernel is an abstraction layer between the hardware and the rest layers of the software stack. It is responsible for device drivers, such as camera and GPS, power management, memory management, security and networking (source.android.com, 2014; Gandhewar and Sheikh, 2010; Song et al., 2010).

Android security mechanism overview

Securing an open-source software stack requires robust and rigorous security mechanism. Android was designed with multi-layered security mechanism, which provides the flexibility required for an open-source platform, while providing protection for user data and system resources, such as networking and storage (Shabtai et al., 2009a; source.android.com, 2014).

Android security mechanism broadly relies on two main security mechanisms: Linux security mechanism and Android application security mechanism, which are presented in the next subsections.

Linux security

Linux kernel is stable and secure kernel, trusted by many corporations and security professionals. Linux kernel provides Android with various security features including: process isolation, access permission model and extensible mechanism for memory protection (source.android.com, 2014; Shabtai et al., 2009a).

Sandboxes
Android inherits Linux sandbox feature to enforce inter-application separation. Each Android application is executed in a separate process. The Android system assigns a unique user ID (UID) to each installed application (source.android.com, 2014; Shabtai et al., 2009a). Sandbox feature isolates applications from each other and from the system. Consequently, each application data and resources are prevented from being used by other applications.

In order for two applications to be executed in the same process, they must be signed by the same private key and share the same UID by declaring sharedUserId attribute in the AndroidManifest.xml file of each application. By doing this, the two applications are then treated as being the same application.

File access
Android relies on Linux discretionary access control (DAC) (Smalley and Craig, 2013; Shabtai et al., 2009a) to protect both applications and system files. Each file is associated with user and group identifier (UID and GID, respectively) and three tuples read, write and execute permissions. Generally, Android system files are owned by superuser or root user, and application files are owned by application user ID (UID). This mechanism prevents one application from directly accessing or altering the files of the system or files of other applications through kernel interfaces.

Memory management
Android is enhanced with many memory management features (source.android.com, 2014) that make common memory corruption issues harder to exploit, including:
• Hardware-based No eXecute (NX) to deny code execution on the stack and heap.
• Linux mmap_min_addr to mitigate null pointer dereference privilege escalation.
• Address space layout randomization (ASLR) and ProPolice to protect from buffer over flow attack.
• Format string vulnerability protections.

Android application security
Additional finer-grained security features are provided at application level to enforce more Android security mechanisms. The two main security features are: application permission and application signing (source.android.com, 2014). First, by default, Android applications cannot access sensitive system resources, such as camera, GPS and network. These functions are protected by security feature known as permissions. Second, all Android applications must be signed digitally by a private key. The signing process identifies application’s developer and detect if the application code altered.

Table des matières

INTRODUCTION 
CHAPTER 1 BACKGOUND: ANDROID SECURITY MECHANISM AND
THREATS
1.1 Android software stack
1.2 Android security mechanism overview
1.2.1 Linux security
1.2.1.1 Sandboxes
1.2.1.2 File access
1.2.1.3 Memory management
1.2.2 Android application security
1.2.2.1 Application permission
1.2.2.2 Application signing
1.3 Android security mechanism limitations
1.4 Smartphone system security threats
1.4.1 Application based threats
1.4.2 Network based threats
1.4.3 Web based threats
1.4.4 Physical threats
1.5 Malware threats
1.5.1 Malware classification
CHAPTER 2 LITERATURE REVIEW 
2.1 Introduction
2.2 Malware detection techniques classification criteria
2.2.1 Reference behavior rule
2.2.2 Analysis techniques rule
2.2.3 Algorithms rule
2.2.4 Dataset rule
2.3 Malware detection techniques classification
2.4 Signature-based detection techniques
2.4.1 Static signatures-based detection techniques
2.4.1.1 Byte code signature
2.4.1.2 Hash signature
2.4.2 Behavior signature-based detection techniques
2.4.2.1 Static behavior signature-based detection techniques
2.4.2.2 Dynamic behavior signature-based detection techniques
2.5 Anomaly-based detection techniques
2.5.1 Static anomaly-based detection techniques
2.5.1.1 Machine learning classifier
2.5.1.2 Code analysis
2.5.2 Dynamic analysis
2.5.2.1 Machine learning classifier
2.5.2.2 Dynamic taint analysis
2.6 Conclusion
CHAPTER 3 SYSTEM CALLS AND FILTERING & ABSTRACTION
PROCESS
3.1 Linux system calls
3.2 Limitation of using system calls
3.2.1 Easy evasion
3.2.2 Complex application behavior
3.2.3 Time and space complexities
3.3 System calls filtering and abstraction process
3.3.1 Filtering phase
3.3.1.1 Inter-Process Communication
3.3.1.2 Memory management
3.3.1.3 Information maintenance system calls
3.3.1.4 Unsuccessful system calls
3.3.2 Abstraction phase
3.3.3 End result
3.4 System call feature vectors
3.4.1 Successive system calls feature vector representation
3.4.2 Bag of system calls feature vector representation
3.4.3 l_Patterns frequency of system calls feature vector representation
3.4.4 Experiments and results
3.4.5 Discussion and conclusion
CHAPTER 4 CANONICAL BENIGN BEHAVIOR DATABASE APPROACH
4.1 Canonical database
4.2 Multi-pattern matching algorithms
4.2.1 Aho-Crosick (AC) algorithm
4.2.2 Commentz-Walter (CW) algorithm
4.2.3 Wu-Manber (WM) algorithm
4.2.4 Set Backward Oracle Matching (SBOM) algorithm
4.2.5 Algorithm requirements
4.3 Measuring abnormal behavior
4.4 Experiments and results
4.4.1 Trace size and resource usage
4.4.2 Anomaly detection
4.4.2.1 The accuracy evaluation
4.4.2.2 Anomaly detection without using the filtering and
abstraction process 95
4.4.2.3 Anomaly detection using the filtering and abstraction
process 98
4.5 Discussion and conclusion
CHAPTER 5 MACHINE LEARNING CLASSIFIERS
5.1 Generative vs discriminative classifier
5.1.1 The support vector machine (SVM) classifier
5.1.2 The k-means classifier
5.1.3 Experiments and results
5.1.3.1 The experiment protocol
5.1.3.2 The dataset for experiments
5.1.3.3 The results
5.1.3.4 Resources usage
5.2 Hybrid classifier
5.2.1 Experiment results
5.3 Discussion and conclusion
CONCLUSION

Télécharger le rapport complet