1. AUDACIOUS: USER-DRIVEN ACCESS CONTROL WITH UNMODIFIED OPERATING SYSTEMS
Talia ringer, dan grossman and Franziska roesner
University of Washington
seattle, Usa
PRESENTED BY: Jay Pandya

2. INTRODUCTION
There is a growing concern around applications asking for all-or-nothing access to user resources – users have no clear indication of what this allows the application to do.
Prior work introduced user-driven access control via access control gadgets (ACGs), but this required direct modification of operating systems and does not provide backwards compatibility.
Examples:
Recently, a flashlight application was recently found to be leaking user location to advertisers.
Android malware is known to sent costly SMS messages without the user knowing
ACGs were a step in the right direction, but the problem of devices running old OS versions still remains.
There is a growing concern around applications (mobile applications in particular) requiring all-or-nothing access to user resources. Allowing this has led to an abuse of the access by malicious applications, wherein the users have no clear indication of what the application is doing with the granted permissions. Prior work in the field introduced user-driven access control via the use of Access Control Gadgets (ACGs). Access Control Gadgets are interactable UI elements which grant the application access to resources external to the application. An example of ACGs on iOS can be the camera and microphone icons – which allow you to attach an image or record audio messages. ACGs, however, require significant modification to operating systems in order to serve as a stand-alone solution to this problem. There are two examples which highlight the severe misuse of user information. The first, was a simple flashlight application that was leaking user location information to advertisers. The second example is a common occurrence, in which android malware sends costly text messages without the user knowing. ACGs were a step in the right direction, but the problem of devices running old OS versions still remains.

3. GOALS OF AUDACIOUS
For a solution to be immediately deployable, AUDACIOUS must build on ACGs by maintaining the following goals:
User-driven Access Control Access to sensitive resources is only granted when the user interacts with the corresponding ACG.
Unmodified Operating System
Regulate Resource use, not just access Design should provide guarantees about the flow of resources.
Permission Model Flexibility Allow applications to use alternative permission models for some functionalities.
The proposed solution is something called AUDACIOUS. It is a way to provide user-driven access control without needing any modification to operating systems whilst being easily deployable. However, in order for this to be possible, AUDACIOUS must build on ACGs by maintaining the following goals. User-driven access control. This means that the access permissions are only granted when the user interacts with the corresponding ACG. Unmodified Operating System. Operating systems shouldn’t need to be modified in order to accommodate for AUDACIOUS. Regulation of resource use, not just access. The design should provide guarantees about the flow of certain resources. Permission Model Flexibility. Certain applications require varying permission models to perform their functions, and AUDACIOUS should cater for that.
Image from:

4. SECURING ACCESS CONTROL GADGETS
Applications include external library in which ACGs encapsulate the details of both resource APIs and UI elements which grant permissions.
The library uses techniques to regulate the following conceptual phases:
Event flow – UI interaction is strictly invoked by the user
UI Context – UI does not trick the user into interactions
Resource flow – Resources are accessed appropriately via ACGs
Event flow
Can be disrupted via event forgery.
Defense via taint analysis.
UI Context
Can be disrupted by cover attacks.
Defense via explicit Internal/External UI checking
Resource flow
Disrupted by abusing granted permissions to perform malicious tasks.
Defense via regulating Information Flow.
EVENT
LIBRARY
So now comes the question of how one may actually secure these access control gadgets. The authors of the article developed an external library in which ACGs encapsulate the details of resource APIs and UI elements. The library uses techniques to regulate three phases. The first one is event flow. Regulation of event flow means that the UI interaction is strictly invoked by the user (not the application). The second, is UI Context. Regulating the UI context ensures that the user is not tricked into performing actions that could jeopardize their personal information. The final phase is Resource flow. This just means that resources are accessed and used in an appropriate manner.
Without AUDACIOUS, these three phases can be easily disrupted by an adversary. Event flows can be disrupted via event forgery, where an application creates a fake event to perform an unexpected task. AUDACIOUS combats this by performing taint analysis on events. An event is marked as tainted if it passes through application code before arriving at an ACG. If an event is tainted, then it doesn’t get executed. The UI Context can be disrupted by cover attacks. Cover attacks occur when the UI is covered with malicious elements in order to trick the user of the application into performing certain tasks. These attacks are mitigated by AUDACIOUS by performing bitmap comparisons of UI elements before and after events. The final phase is Resource flow. We’ve already covered an example of this earlier when we talked about the flashlight application.
EXECUTE EVENT

5. ACG LIBRARY SPARTA LIBRARY Developed in Android and is event-driven.
Application developers include the library and use its UI elements.
Invalidates view if library detects a potentially malicious or “evil” event. Application code is not executed.
Two ACG interfaces – one for temporary permissions and one for permanent permissions.
Views are wrapped so that applications cannot modify the ACG UI after creation.
SPARTA LIBRARY
Information flow tool
Two stages - App store approval and Runtime approval
SPARTA operates on source code and uses static type- checking to infer illegal flow of information.
All allowed flows are defined in a flow policy file
A human verifies the output of SPARTA in the context of the policy.
SPARTA is extended by implementing an ACG type so SPARTA can distinguish ACGs from each other.
So how does AUDACIOUS actually do these things? It makes use of two libraries – the ACG Library and the SPARTA library. The ACG Library is developed by the authors in Android, and is event driven. Before starting development of an android application, developers include this library in their project and use its UI elements instead. The ACG library employs many different techniques to protect against all kinds of attacks but the most common type of attack is related to events. Views must go through the ACG library before they are passed on to the application code. A view will be invalidated (or marked as tainted) if it is detected to be malicious. If a view is invalidated, then its corresponding application code is not executed. The library also supports flexible permission models, because there are two available ACG interfaces – one for temporary permissions, and one for permanent. Some adversaries might try to modify the ACG UI after creation in order to bypass these techniques, so this is mitigated by wrapping all the views (with a ViewWrapper).
The second library is called SPARTA. It is an information flow monitoring tool which has two stages – app store approval and runtime approval. While the ACG library focuses on event flows and UI context, the SPARTA library is responsible for ensuring that resource flow within an application is appropriate. It operates on the application source code, and uses static type-checking to infer illegal flows of information. All legal information or resource flows are defined in a flow policy file which is cross-checked during runtime. A human must then go through the output of SPARTA and verify that the information flows are indeed appropriate. SPARTA, however, does not account for WHEN resources are being accessed by applications. Therefore, the SPARTA library was extended by implementing ACG types, allowing SPARTA to distinguish when resources flow from one ACG to another.

6. INTEGRATING AUDACIOUS WITH REAL APPLICATIONS
Implementing the ACG library in some applications actually decreased code size.
In complex applications, the code additions are minimal for the most part.
Classes of attacks were instantiated and tested against a malicious test application. 55 out of 57 attacks were mitigated by AUDACIOUS.
AUDACIOUS uses a Random Check Frequency to ensure that the user has enough time to perceive the UI before any interaction.
If these checks are done frequently, they provide better protection against timing-based attacks.
However, performing the checks at smaller frequencies significantly impacts performance.

7. BENEFITS OF A USER-SPACE APPROACH
Deployability
Changes to OS are costly – so it is very unlikely for OS developers to deploy fixes to issues in the near future.
Even if OS changes were deployed, old devices running previous versions of the system would never receive these changes.
Flexibility of Permission models
Permission models are not one-size-fits-all. It makes sense for different applications to require different permission models.
The user-space approach allows for the permission model to be changed or combined with other models.

8. LIMITATIONS OF A USER-SPACE APPROACH
Increased trusted code base
Have to now assume that the device, OS, ACG library and the device itself haven’t been compromised.
Software updates
If the ACG library is updated, each application developer has to individually update their application to include the latest version of the library.

9. LIMITATIONS CONT. Inconsistent permission models Reflection
Existing permission prompts become redundant with the use of ACGs.
Existing prompts cannot be removed without OS modification.
Reflection
Unrestricted use of reflection allows any secure library to be circumvented.
Requires application developers to use appropriate annotations if reflection is being used.

10. CRITICISM
Use of AUDACIOUS cannot be enforced in any way. It is a choice the developer has.
Does not protect against ALL possible attack types – e.g. Bait-and-switch attacks.
Existing applications do not benefit from AUDACIOUS unless they are completely refactored.
AUDACIOUS only supports 4 types of ACGs – immediate/periodic locations and recording/playing audio. This restricts the functionalities that can be protected by AUDACIOUS.
Some aspects of AUDACIOUS may impair application performance such as the random check frequency.
Code changes may not be manageable (nor feasible) for extremely complex applications.
Doesn’t make sense to develop using AUDACIOUS if the developer is a trusted entity.

11. QUESTIONS?