Zakir Ali Cs 710_Research Paper
Android is widely used mobile operating
system. It has its own security mechanism which makes the mobile secure for
communication. For this purpose Dalvik Virtual Machine (DVM) is available in
Android operating system which deals the security related issues efficiently.
Android operating system is and opens source operating system so the
probability of security issues is high which make the Android operating system
less secure. The vulnerable challenges are late update software, inefficiency
in the kernel; rooted phones disable many security features and Android
challenges, Operating System, Android ,
Now a days
android operating system is on top of other operating system. In android
operating system it has its own specific security mechanism. Dalvik Virtual
Machine (DVM) is used for this purpose. Dalvik Virtual Machine and Linux
platform do this task using the file permission and user identifiers. User ID
is provided for every user and application. Android operating system cannot
access the data or code from any other application. Android operating system is
an open source software. It is used by different types of users so it is high
probability for different kind of issues and challenges. In this paper Section
2 covers the Android Security Mechanism. Section 3 presents android security
challenges, section 4 depicts possible solutions for the Android Challenges and
section 5 shows conclusion remarks.
2. Android Security Mechanism
This section is
about Android internal Security Mechanism which makes the mobiles and it data
more secure and reliable for the customers/users.
Dalvik Virtual Machine (DVM)
Dalvik Virtual Machine (DVM) is responsible for running every
application separately. Zygote makes a virtual machine for every application
and process. Every process has its own process ID and it is used for security
purpose. Fig (a) represents the concept.
Android Plat Form
Android security is embedded in hardware. Its security relies on secure
boot process. CPU starts execution from its reset vector to initial boot-loader
(IBL). Initial boot loader (IBL) loads the boot medium to RAM and makes a
signature check to ensure that only authenticate code is executed. Then Linux
Kernel is loaded by boot loader and also signature checked. The kernel
initializes all the hardware. Then 1st process “init” is called.
Init reads all the files and boots the rest of Android user land.
Mobile devices are strict scrutiny which makes secure boot up process.
The operators provide certifications which makes the mobile operating system
secure and harmless to the cellular network. In rooting system partition is
also required which is not available by default. Root Permission is required.
Two ways are available for this permission. Either by the customer boots that
gives him a root shell or he exploits a vulnerability to gain root permission.
Rooting has repercussion on device security kernel may have malware that runs
with full permission and is undetected by antivirus software. Rooted device do
not gain over the updates. It an application has gained root permission it may
do as it with the device and its data including duplicating, changing and
discarding private information and even bricking the device by overwriting the
and services have potentialities to protect the data and devices by using
access control mechanism. An application declares the permission which needs in
it Android Manifest,xml like access to
contact send and receive SMS. Those permission are presented to the user at the
time of installation of an application user may allow or deny these permission.
However the user may modify the list of permission after the installation
process too according to his/her desire. Fig (b) , (c) ,(d) and (e)
Exhibit this concept.
Memory Corruption Mitigation
mmap-min-addr to mitigate null point de-reference privilege escalation attacks
mmap-min-addr reserves the minimum virtual address a process is allowed to
mmap. Before the attacker writes “0x0” in the process a null pointer de- reference
in kernel then it would make the kernel access page to zero that is filled by
bytes under the control of the attacker. In Android 2.3 the eXecute Never (XN)
bit mark memory pages as non executable. Which does not allowed code execution
on the stack and not allows code execution on the stack and the heap. This does
not allow the attacker to put his own code. In Android 4.0 the address layout
randomization (ASLR) was built. The Linux kernel for (ARM) supports (ASLR). The
Linux kernel randomizes the stack address and the brk memory area. The brk( )
system call allocate the heap for a process.
There are two
ways to enable the (ASLR) either 1 or 2. In case of 1 independent execution
(PIE) and randomize linker to support ASLR with it the location of the binary itself
is randomized. In android 4.1 read only relocation (RELro) and binding is
introduced. ELF uses global offset table (GOT) to locate functions dynamically
link library to resolve the function.
Android Security Enhancement
In Android 4.2 Google has included some
features. The user may modify application prior to installation known as on
device Bouncer. It scans malwares and informs the user if it is harmful. With
Android 4.2.2 Google introduced USB debugging. Only authenticated devices are
allowed to connect via USB to the mobile device.
Android allows operating system services to run without root privileges.
Android operating system has many challenges
some of them are identified here.
3.1 Delayed System Update
Android is an open source operation system.
The custom component is supplied by Google Inc. Android is built on Web kit and
Linux kernel. These components are loosely coupled and the source code
repository is available for public and bug trackers are also publically
available. The time span of discovery of bug detection and deployment security
patch is critical. Meanwhile the attackers may exploit the software. The
vulnerabilities are spread over the market till the resulting patch is
available in the repository. Which enhance the vulnerabilities for attackers;
he can exploit and attack unmatched systems.
Hence timely patch deployment is sine qua non for the system’s security.
To set themselves, device makers augment
Android with custom user interfaces and features. These additions require depth
modification of source code. Google develops behind the doors. This style has
certain drawbacks that the device vender cannot keep their source tree up to
date. Hence custom user interfaces and features to new version till the new
code is generated by Google. After deploying the feature it must go to quality
management. This process is time consuming and costly effort that are often not
Keeping the software up date is not valuable
for the device makers in term of market value when the device is sold. Android
has not the facility of selecting updates but depends on the whole system image
that have to be provided by the device makers Hence the device makers do not
fix individual vulnerability but accumulate update.
These factors become the main reasons of
delay deployment of updates, those results in large number of devices with
known and un-patched vulnerabilities. Security features like full disk
encryption are introduced with new Android versions, but are not back ported to
Furthermore that majority of Android users
have old versions of Android. The Google’s attempts to introduce newer and
better security has limited effects for device that are deployed
3.2 Linux Kernel
Android operating system is based on Linux
kernel. Linux implements monolithic software architecture. All components and
device drivers run on kernel mode where no separation in component is provided.
Any bug that may be exploited enables an attacker to change kernel memory and
here by mitigate all security measures of kernel. Hence kernel update by
testing and validating of kernel code is sine qua non to Android security.
Device makers often need to implement custom
drivers for hardware Linux community. As a result these drivers do not go to
the community review process and are often poor quality. Shifting the drivers
to new versions of Linux is often not considered worth the efforts due to cost
problems and the task required for testing and validation. Hence the out dated
Linux Kernel is run on many devices. Fig (f)
integrity barriers are overcome by rooting process. It can happen in two ways
the 1st way is the voluntarily by the user who likes to be able to
install additional unauthorized application the 2nd way is by
malware, in order to receive maximum privileges on the infected system. This
type of rooting is gained by exploiting known security flows in mobile phones
device operating system.
tampering in the operating system kernel abolishes integrity. The rooted system
cannot trust in its kernel. The modified kernel might disable Android security measures;
it can alter the system’s behaviour to leak private information. Hence rooting
is a big issue to mobile security.
implements mandatory access control (MAC) in the form of permission system. At
the installation time an application can request permission to access system
resource like location, Internet, or the cellular network from the user. Then
the user may allow or deny to cancelling the installation process. It is
impossible to selectively accept or deny access privileges. Many users accept
the permission without known their implications.
Another issue is that the permission are too coarse
grained. If an application is allowed Internet access, it is free to
communicate with any server on the Internet. If the application is given access
to the Android address boot nothing prevents it for sending the address book’s
content to remote server.
Android market many applications have been distributed, its acceptance process
has the potential to filter malicious application.
4.1 Timely security updates
The timely security updates are sine qua non for any
secure system. It is more important for open source system where the code is
available publically and bugs are easy to spot for mobile devices an update
system has to take all involves
parties into account.
Control plat form diversity
The operating system
developers should include third
modification to the operation system do not introduce
breaches by design. The developer should pay attention
security critical points in the system that third party code has
4.3 Ensure Lock Screen under all
Ensure that no any other party can unlock the screen.
4.4 Design permission system with user and developer
permission system must be developed that the user both understands the
functionality so that one can make an educated decision when granting
permission. Giving permission at the installation time is problematic. After
giving permission user may able to install the application. It may be better to
ask the user to grant permission when it is needed.
4.5 Ensure that the App market does not
people trust in App market and have no chance to determine the quality of an
App by them. Aside from having a mandatory permission process an App market
must also scan for repackaged.
architecture is vulnerable for security threats. The weakness and strengths of
Android operating system have been highlighted in this paper. Security challenges/issues/problems
and measures have been identified. Some
solutions are also presented to overcome the security pitfalls and enhance the
In this paper the
Android security mechanism, Android security challenges/issues/problems/threats
and security measures are described.
I am thankful to the course instructor who has guided
and encouraged me to write this paper.
1. Grace, M.,
Zhou, Y., Wang, Z., and Jiang, X. Systematic detection of capability leaks in
stock Android smart phones. Network and Distributed System Security Symposium
2. Soghoian, C., and Wizner, B. ACLU FTC Android
updates. 2013. url: http://www.aclu.org/files/assets/aclu_- _android_ftc_complaint_-_final.pdf.
Bellissimo, A., Burgess, J., and Fu, K. Secure software updates:
disappointments and new challenges. In: USENIX Hot Topics in Security. USENIX,
4. Arp, D., Spreitzenbarth, M., Malte, H., Gascon,
Rieck, K. Drebin: E?ective and
Malware in Your Pocket. In: Network and
System Security (NDSS). Internet Society, San Diego, CA, USA, 02/2014, 23–26.
5. IEEE COMMUNICATIONS SURVEYS AND TUTORIALS, VOL.
00, NO. 0, FEBRUARY 2014
6. ACM Computing Surveys, Vol. 49, No. 2, Article 38,
Publication date: August 2016.
7. Bernstein, D.J.: CAESAR: Competition for
authenticated encryption (Dec 2015), http://competitions.cr.yp.to/caesar.html
8. Teu?, P., Fitzek, A.G., Hein, D., Marsalek, A.,
Oprisnik, A., Ze?erer, T.: Android encryption systems. In:
International Conference on Privacy & Security in Mobile Systems (2014)
9. Abhishek Dubey, Anmol Misra, Android Security:
Attacks and Defenses, Taylor and Francis Group, 2013, ISBN: 978-1-4822-0986-0
10. Ryan Farmer, A Brief Guide to Android Security,
Acumin Consulting Rafael Fedler,
Christian Banse, Christoph Krauss, Volker Fusenig, Android OS Security: Risks
and Limitations, 2012, Fraunhofer Research Institution for Applied and
11. Android (operating system,
http://en.wikipedia.org/wiki/Android_(operating_system), A Wikipedia article with some introductory information
about the Android platform.
12. The Complete Android Guide for Everyone,
looking-for-an-android-guide/, A simple guide for users new to Android devices.
13. Android Rooting Risks,
rooting-risks.aspx, An article detailing the security risks associated with
rooting an Android device.
14. Android Security Overview,
https://source.android.com/devices/tech/security/, A webpage that goes into
detail on how the Android security model was built and its functionality.nd Challenges