Syracuse University, New York, USA

Slides:



Advertisements
Similar presentations
Information Security Domains Computer Operations Security By: Shafi Alassmi Instructor: Francis G. Date: Sep 22, 2010.
Advertisements

Securing Enterprise Networks with Traffic Tainting Anirudh Ramachandran Nick Feamster Yogesh Mundada Mukarram bin Tariq.
Operating System Security
Xiao Zhang and Wenliang Du Dept. of Electrical Engineering & Computer Science Syracuse University.
Internet of Things Security Architecture
Joshua Fabian Tyler Young James C. Peyton Jones Garrett M. Clayton Integrating the Microsoft Kinect With Simulink: Real-Time Object Tracking Example (
Ensuring Operating System Kernel Integrity with OSck By Owen S. Hofmann Alan M. Dunn Sangman Kim Indrajit Roy Emmett Witchel Kent State University College.
Aurasium: Practical Policy Enforcement for Android Applications By Yaoqi USENIX Security Symposium 2012.
What’s new in this release? September 6, Milestone Systems Confidential Milestone’s September release 2012 XProtect ® Web Client 1 Connect instantly.
1 Chapter 8 Fundamentals of System Security. 2 Objectives In this chapter, you will: Understand the trade-offs among security, performance, and ease of.
Android Security. N-Degree of Separation Applications can be thought as composed by Main Functionality Several Non-functional Concerns Security is a non-functional.
An Evaluation of the Google Chrome Extension Security Architecture
By : Versha Thakur Shravani Aishwarya
Aurasium: Practical Policy Enforcement for Android Applications R. Xu, H. Saidi and R. Anderson Presented By: Rajat Khandelwal – 2009CS10209 Parikshit.
Protecting User Data in Ubiquitous Computing: Towards Trustworthy Environments Yitao Duan and John Canny UC Berkeley.
System Center Configuration Manager Push Software By, Teresa Behm.
Traffic Management - OpenFlow Switch on the NetFPGA platform Chun-Jen Chung( ) Sriram Gopinath( )
Maintaining and Updating Windows Server 2008
Check Disk. Disk Defragmenter Using Disk Defragmenter Effectively Run Disk Defragmenter when the computer will receive the least usage. Educate users.
Android Security Enforcement and Refinement. Android Applications --- Example Example of location-sensitive social networking application for mobile phones.
Overview SAP Basis Functions. SAP Technical Overview Learning Objectives What the Basis system is How does SAP handle a transaction request Differentiating.
Case study 2 Android – Mobile OS.
CS 153 Design of Operating Systems Spring 2015 Lecture 24: Android OS.
D ATABASE S ECURITY Proposed by Abdulrahman Aldekhelallah University of Scranton – CS521 Spring2015.
Microsoft ® Official Course Module 9 Configuring Applications.
Understanding Android Security Yinshu Wu William Enck, Machigar Ongtang, and PatrickMcDaniel Pennsylvania State University.
Storage Security and Management: Security Framework
Introduction to Android Swapnil Pathak Advanced Malware Analysis Training Series.
WINDOWS SERVICES. Introduction You often need programs that run continuously in the background Examples: – servers –Print spooler You often need.
All Your Droid Are Belong To Us: A Survey of Current Android Attacks 단국대학교 컴퓨터 보안 및 OS 연구실 김낙영
Information Systems Security Computer System Life Cycle Security.
Controlling Files Richard Newman based on Smith “Elementary Information Security”
An Overview of MPEG-21 Cory McKay. Introduction Built on top of MPEG-4 and MPEG-7 standards Much more than just an audiovisual standard Meant to be a.
Securing Embedded User Interfaces: Android and Beyond Franziska Roesner and Tadayoshi Kohno University of Washington Mohamed Grissa A presentation of USENIX.
User Interface Toolkit Mechanisms For Securing Interface Elements Franziska Roesner, James Fogarty, Tadayoshi Kohno Computer Science & Engineering DUB.
USER DRIVEN ACCESS CONTROL: RETHINKING PERMISSION GRANTING IN MODERN OPERATING SYSTEM Presentation by: Manik Challana Presented at : IEEE Symposium on.
2011/12/20 1 Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Syracuse University ACSAC 2011.
ANDROID L. Grewe Components  Java Standard Development Kit (JDK) (download) (latest version)  AndroidStudio.
UNIX System Protection. Unix History Developed by Dennis Ritchie and Ken Thompson at AT&T Bell Labs Adapted some ideas from the Multics project in 1969.
Traffic Management - OpenFlow Switch on the NetFPGA platform Chun-Jen Chung( ) Sriram Gopinath( )
M. Alexander Helen J. Wang Yunxin Liu Microsoft Research 1 Presented by Zhaoliang Duan.
Multics CysecLab Graduate School of Information Security KAIST.
Operating Systems Security
Android System Security Xinming Ou. Android System Basics An open-source operating system for mobile devices (AOSP, led by Google) – Consists of a base.
Android Permissions Demystified
VMM Based Rootkit Detection on Android
Race conditions and synchronization issues Exploiting UNIX.
4P13 Week 5 Talking Points 1. Security Provided by BSD a self-protecting Trusted Computing Base (TCB) spanning kernel and userspace; kernel isolation.
Security-Enhanced Linux Stephanie Stelling Center for Information Security Department of Computer Science University of Tulsa, Tulsa, OK
DeepDroid Dynamically Enforcing Enterprise Policy Manwoong (Andy) Choi
Android and IOS Permissions Why are they here and what do they want from me?
Chapter 29: Program Security Dr. Wayne Summers Department of Computer Science Columbus State University
“What the is That? Deception and Countermeasures in the Android User Interface” Presented by Luke Moors.
The Ingredients of Android Applications. A simple application in a process In a classical programming environment, the OS would load the program code.
WHAT THE APP IS THAT? DECEPTION AND COUNTERMEASURES IN THE ANDROID USER INTERFACE.
ANDROID ACCESS CONTROL Presented by: Justin Williams Masters of Computer Science Candidate.
Security Development Lifecycle (SDL) Overview
Containers as a Service with Docker to Extend an Open Platform
Free for All! Assessing User Data Exposure to Advertising Libraries on Android Campbell Foskin.
Understanding Android Security
Boxify: Full-fledged App Sandboxing for Stock Android
Life after App Uninstallation: Are the Data Still Alive
Outline What does the OS protect? Authentication for operating systems
TaintART: A Practical Multi-level Information-Flow Tracking System for Android RunTime Sadiq Basha.
Introduction to Operating System (OS)
Outline What does the OS protect? Authentication for operating systems
UNIX System Protection
Chapter 29: Program Security
Understanding Android Security
Emerging Platform#3 Android & Programming an App
Presentation transcript:

Syracuse University, New York, USA A Systematic Security Evaluation of Android’s Multi-User Framework Paul Ratazzi, Yousra Aafer, Amit Ahlawat, Hao Hao, Yifei Wang, Wenliang Du EECS Syracuse University, New York, USA MoST Workshop

Outline Introduction & Motivation Background: Implementation Methodology Hypotheses & Findings Conclusion -capabilities that secondary users are not supposed to have

Introduction and Motivation Two new ways of sharing Android tablets Multiple Users (MU) – introduced in 4.2 Restricted Profiles (RP) – introduced in 4.3 Google's advice to share “only with people you trust” raises questions about security and privacy Our work Understand the implementation Develop a systematic evaluation methodology Generate hypothesis Test hypothesis to demonstrate specific vulnerabilities -capabilities that secondary users are not supposed to have

Background: Implementation (1/2) Framework – userId uid = userId * PER_USER_RANGE + (appId % PER_USER_RANGE) e.g., app 10056 runs as uid 0010056 for user 0 (Owner) and uid 1010056 for user 10 Framework – Permissions MANAGE_USERS, INTERACT_ACROSS_USERS, INTERACT_ACROSS_USERS_FULL (systemOrSignature) -capabilities that secondary users are not supposed to have

Background: Implementation (2/2) Framework - Package management Each userId has its own set of enabled app Filesystem User-specific package data isolated under /data/user/<userId> External storage isolated by way of Linux mount namespaces Kernel No changes necessary Run-time Concept of current user vs. inactive user(s) PM allows different users to choose different set of apps. It also allows owner to choose which apps are allowed for RPs However, the framework is actually platform centric. An app is only installed once for the whole platform but only enabled or disabled For specific users. Package list maps packages names to corresponding data directories , appIds, gids. No changes at level of kernel since linux is naturally a multi user system  userid + appId = uid

Methodology (1/3) Identify subjects associated with secondary user Apps and activities Identify objects shared among users Evaluate access control path between subjects and objects Does access control exist along path? Is the subject properly identified (user, app, state, etc.)? We begin with Yaghmour’s [5] high-level architectural view shown in Fig. Various categories of system resources We rely on this diagram to identify objects and subjects that have interesting security aspects unique to multi-user Then we evaluate the suitability of the access control paths between them. subjects: apps, stock apps Objects: resources: public interfaces of other apps, services, abstracted hardware devices, kernel objects

Methodology (2/3) Access control paths IPC to service or provider IPC to exported activity System call Person None Access path between subjects and objects

Methodology (3/3) Insights & observations... Lead to questions: Multi-user features have introduced important new considerations for the subjects and objects identified Several access control paths have been modified to account for the presence of multiple users Lead to questions: Do Android’s access control points properly account for the new considerations regarding subjects and objects? If not, can a secondary user exploit these shortcomings, and what is the potential damage? Establish a set of working hypotheses -capabilities that secondary users are not supposed to have

Findings: Unprotected Activities Hypothesis 1: “Secondary users may be able to bypass their restrictions by exploiting the unprotected public interfaces of system apps”. We systematically compared the Settings UI elements accessible to the owner with that of a secondary user. Settings app implements restrictions based on type of user by hiding certain menu items, while their corresponding activities are exported. Secondary users can launch these hidden activities directly via intents and bypass the intended restrictions ! Examples: VPN Settings, Mobile network, mobile plan settings, etc…

Findings: Unrestricted Administrative Functions Hypothesis 2: “Secondary users may be able to maliciously reconfigure critical platform-wide settings that are persistent across user switches”. Secondary users possess certain administrative capabilities which are normally preserved for privileged users. Secondary users can set a malicious environment for the owner to use. Examples: Wi-Fi Settings can be changed by secondary users and are persistent across users. Attack: Connect to a malicious hotspot to control all traffic to/from device.

Findings: Use of Sensors and Hardware Devices: Hypothesis 3: “Inactive users may be able to spy on active users by exploiting improper access control enforcement on shared hardware resources”. If no proper access control, a non-current user can spy on logged-in user. To ensure that a hardware resource is only bound to currently logged-in user: Identify if the user requesting the resource is logged-in. Track if the user who initiated the request is continuously logged-in during the service lifetime. dIf Android does not enforce proper access control on media/sensors resources based on user status, a non-current user can spy on logged-in user.

Findings: Exploiting Media Resources Two access control points should be enforced by the MediaServer: At Request time: check if the userid is equal to current userid. At User switch time: revoke any resources accessed. We designed an app that launches the camera under two scenarios: The app schedules video recording when the victim user is logged in. The app starts video recording immediately while attacker is logged in. Success on both scenarios: There is no access control based on user status at request time, nor at user switch time! To ensure that a media resource is not accessible to a non-logged in user, We investigated the MediaServer and confirmed this observation.

Findings: Exploiting Media Resources -capabilities that secondary users are not supposed to have

Findings: Exploiting Motion, Environmental and Position Sensors SensorService should apply at least one of the following access controls: At Registration time/Switch time: only allow current users to register listeners, and unregister all listeners one a switch happens. At Dispatch time: deliver sensor updates only to listeners belonging to current users. We designed an app that: schedules registration to receive sensor event when the victim user is logged in. registers a listener to receive sensor events when the attacker user is logged in. In both two scenarios, the app is able to receive sensor updates about victim user!! To ensure that a non-logged in user cannot receive sensor updates, the

Findings: Shared Package Information Hypothesis 4: “sharedUserId permissions may not be properly separated when sharedUserId apps are installed by different users:” Although sharedUserId app’s data is properly isolated in multi-user, this is not the case with permissions! Permissions are leaked across user boundaries between apps sharing the same UserId. Cause: Platform centric design of PackageManager. We created a pair of sharedUserId apps belonging to different users. Each one of them declares a different permissions. The effective permissions assigned is the union of all permissions.

Findings: Shared Package Information Hypothesis 5: “A malicious user may exploit the shared package management to modify another user’s app bytecode or prevent them from installing apps” All users share the same package code for a specific package name. If a package has been installed for a specific user, the PackageManager will consider it an update. DoS: A malicious user can install 50000 dummy apps to prevent other users from installing new apps. -capabilities that secondary users are not supposed to have

Conclusion Description of the multi-user support Systematic approach for studying if proper access control is enforced Provide insights into potential problems through a comprehensive analysis of object/subject resources Several concerns -capabilities that secondary users are not supposed to have