Android Security Modules (ASM)
Android, iOS, and Windows 8 are changing the application architecture of consumer operating systems. These new architectures required OS designers to rethink security and access control. While the new security architectures improve on traditional desktop and server OS designs, they lack sufficient protection semantics for different classes of OS customers (e.g., consumer, enterprise, and government). The Android OS in particular has seen over a dozen research proposals for security enhancements.
We seek to promote OS security extensibility in the Android OS. We propose the Android Security Modules (ASM) framework, which provides a programmable interface for defining new reference monitors for Android. We drive the ASM design by studying the authorization hook requirements of recent security enhancement proposals and identify that new OSes such as Android require new types of authorization hooks (e.g., replacing data). We describe the design and implementation of ASM and demonstrate its utility by developing reference monitors called ASM apps. Finally, ASM is not only beneficial for security researchers. If adopted by Google, we envision ASM enabling in-thefield security enhancement of Android devices without requiring root access, a significant limitation of existing bring-your-own-device solutions.
For more information on ASM, including source code, please visit androidsecuritymodules.org.
NativeWrap is an application wrapper for Android that configures native Android applications from URLs supplied by the user, which are then installed on the device. The whole process takes little or no effort from the user, as NativeWrap's WebView wrapper comes preconfigured with security best practices (for e.g. SSL Pinning, Force HTTPS, etc.).
For more information on NativeWrap, including source code and link to Google Play Store version, please visit research.csc.ncsu.edu/security/nativewrap.
Modern OSes such as Android, iOS, and Windows 8 have changed the way consumers interact with computing devices. Tasks are often completed by stringing together a collection of purpose-specific user applications, as shown in the figure above (e.g., a barcode reader, a social networking app, a document viewer). As users direct this workflow between applications, it is difficult to predict the consequence of each step. Poor selection may result in accidental information disclosure when the target application unknowingly uses cloud services. Aquifer is a policy framework and system for preventing accidental information disclosure in modern operating systems. In Aquifer, application developers define secrecy restrictions that protect the entire user interface workflow defining the user task. In doing so, Aquifer provides protection beyond simple permission checks and allows applications to retain control of data even after it is shared.
For more information on Aquifer, including source code, please visit research.csc.ncsu.edu/security/aquifer.
Application markets such as Apple’s App Store and Google’s Play Store have played an important role in the popularity of smartphones and mobile devices. However, keeping malware out of application markets is an ongoing challenge. While recent work has developed various techniques to determine what applications do, no work has provided a technical approach to answer, what do users expect? In this paper, we present the ﬁrst step in addressing this challenge. Speciﬁcally, we focus on permissions for a given application and examine whether the application description provides any indication for why the application needs a permission. We present WHYPER, a framework using Natural Language Processing (NLP) techniques to identify sentences that describe the need for a given permission in an application description. WHYPER achieves an average precision of 82.8%, and an average recall of 81.5% for three permissions (address book, calendar, and record audio) that protect frequently used security and privacy sensitive resources. These results demonstrate great promise in using NLP techniques to bridge the semantic gap between user expectations and application functionality, further aiding the risk assessment of mobile applications.
For more information on WHYPER, including source code and data sets, please visit sites.google.com/site/whypermission/.
Smartphone applications are frequently incompletely vetted, poorly isolated, and installed by users without restraint. Smartphone research frequently needs to understand how these applications behave. ded is a project which aims at decompiling Android applications. The ded tool retargets Android applications in .dex format to traditional .class files. These .class files can then be processed by existing Java tools, including decompilers. Thus, Android applications can be analyzed using a vast range of techniques developed for traditional Java applications.
For information regarding obtaining and using ded, please visit siis.cse.psu.edu/ded.
As part of theh ded project, we developed custom static analysis rules for the (now HP) Fortify Static Code Analyzer (SCA) tool. These rules test for a breadth of security vulnerabilities and dangerous functionality, as described in our USENIX Security paper. The specific rules are explained in more detail in our Technical Report. The final Fortify SCA ruleset used for this paper is available at the below link.
The TaintDroid project provides realtime analysis to watch how applications use different types of privacy sensitive information. TaintDroid uses dynamic taint analysis to track taint markings assigned to data when it is accessed from application programming interfaces. When information leaves the phone's network interface, TaintDroid records any present taint markings. To provide realtime analysis on smartphones, TaintDroid has a carefully designed architecture, trading tracking granularity for performance.
For information regarding obtaining and building TaintDroid, please visit appanalysis.org.
XATTR Support for YAFFS2
During my research with the Android smartphone platform, I've needed to store security information in XATTRs. Unfortunately, Android uses the YAFFS2 NAND file system on many of its devices, and YAFFS2 doesn't support XATTRs out of the box. The following patch is my implementation of XATTR support for YAFFS2.
The Android boot.img file contains a kernel and a ramdisk. While researching Android, I've needed to manipulate the ramdisk of a phone. I created the split_bootimg.pl script to parse the boot.img file format and extract the parts.
The following example uses the boot.img from the full TC4-RC28 update:
% ./split_bootimg.pl boot.img Page size: 2048 (0x00000800) Kernel size: 1388548 (0x00153004) Ramdisk size: 141518 (0x000228ce) Second size: 0 (0x00000000) Board name: Command line: no_console_suspend=1 Writing boot.img-kernel ... complete. Writing boot.img-ramdisk.gz ... complete.
Extract the ramdisk.
% mkdir ramdisk % cd ramdisk % gzip -dc ../boot.img-ramdisk.gz | cpio -i % cd ..
Make any changes necessary (e.g., set ro.secure=0 in default.prop).
Recreate the cpio archive using the mkbootfs binary produced from building the Android source code (The cpio utility in OS X does not recognize the newc format, therefore mkbootfs is the best option for OS X users).
% mkbootfs ./ramdisk | gzip > ramdisk-new.gz
Recreate the image file using the mkbootimg binary produced from building the Android source code.
% mkbootimg --cmdline 'no_console_suspend=1 console=null' \ --kernel boot.img-kernel \ --ramdisk ramdisk-new.gz \ -o boot-new.img
- For Nexus One: Add --base 0x20000000 to mkbootimg command-line.
- The console=null command line option was introduced in the TC4-RC30 boot images to remove the root shell
- Do not use a boot.img image extracted directly from /dev/mtd/mtd2. This image may become corrupted during the read process.