Permission Re-delegation - University of California, Berkeley

crookpatedhatΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 7 μήνες)

86 εμφανίσεις

PERMISSION RE
-
DELEGATION:

ATTACKS AND DEFENSES

Adrienne Porter Felt
1
, Helen J Wang
2
, Alexander Moshchuk
2
,
Steve
Hanna
1
, Erika Chin
1


1
University of California, Berkeley

2
Microsoft Research

1

MODERN CLIENT PLATFORMS


Applications are untrusted, or partially trusted


Isolated from each other, except for IPC


By default, denied access to private devices and data



Users explicitly grant permissions for devices, data



Each application may have its own set of permissions






2

PERMISSIONS

Android,
iOS
, HTML5, browser extensions…

3

PERMISSION RE
-
DELEGATION


Permission re
-
delegation

occurs when an application
without a permission gains additional privileges through
another application



A special case of the confused deputy problem


Privilege obtained through user permissions



4

5

I removed the attack demo due to the PPTX file size.

To see the attack demo:

https
://
plus.google.com
/photos/110581955720098741626/albums/563827
7509860549393/5638277512553016018

6

API

Settings

Demo
malware

toggleWifi
()

pressButton
(0)

Permission System

THIS TALK


Our threat model



Permission re
-
delegation is a real problem, and

s
ystems should not permit permission re
-
delegation



We propose IPC Inspection as a defense mechanism



7

THREAT MODEL

8

API

THE PERMISSION SYSTEM


Permission system enforces
user’s permission policy

Malware

Deputy

toggleWifi
()

9

Permission System

toggleWifi
()

THE DEPUTY



Has user authorization



Not malicious, but not a
security watchdog



Exposes public services
Confused? Careless?

Malware

Deputy

Malware

10

API

Permission System

toggleWifi
()

THE ATTACKER


User installs/runs it, but
doesn’t trust it



Exploits a deputy to access
a resource


Malware

API

Deputy

Malware

toggleWifi
()

pressButton
(0)

11

Permission System

REAL WORLD

PERMISSION RE
-
DELEGATION

ATTACKS

Android case study,

p
recautionary for the future of the web

12

IDENTIFYING CANDIDATES


Two necessary preconditions for an attack:


Has a dangerous permission


Has a public interface



Analyzed manifests of 872 Android applications


16 system apps, 756 most popular, 100 recently uploaded



320 apps (
37%
) are candidates for attacks



13

FINDING EXPLOITS


Built tool
for
finding attacks



Call graph analysis:

find paths from public entry
points to protected API calls



Manually verified all exploits


14

Public

e
ntry points

API calls

ATTACKS



Built attacks using 5 of the 16 system apps



Found 15 attacks in the 5 applications



Several confirmed and fixed



This is a lower bound; likely more exist


15

16

API

Settings

Demo
malware

wifiManager.setWifiEnabled
(true)

Message:

0://0#0

Permission System

ATTACK ON THE SETTINGS APP

com.android.settings.widget
.

SettingsAppWidgetProvider

User
pressed
button[0]

MORE EXAMPLE ATTACKS


DeskClock
:


Start an internal service


Tell it to infinitely vibrate with a WAKE_LOCK on



Phone:


Trigger the “phone call answered” message receiver


Phone call will be silenced, vibrate cancelled



17

PREVENTING

PERMISSION RE
-
DELEGATION

18

OUR GOALS


We don’t want to rely on application developers for
prevention



Enable the system to prevent permission re
-
delegation



We don’t want to break applications


19

IPC INSPECTION


When a deputy receives a message,

system reduces
deputy’s permissions (for the session) to:


{requester’s permissions} {deputy’s permissions}



A deputy’s current set of permissions captures its
communication history



Deputy can specify who can(not) send it
messages



Generalizes stack inspection to IPC calls


20

NON
-
MALICIOUS EXAMPLE

21

Mapping App


USER LOCATION

GPS STATE

Settings App


GPS STATE

BLUETOOTH STATE

Toggle GPS

toggleGPS
()

API

Permission System

MALICIOUS EXAMPLE

22

Malware

Settings App


GPS STATE

BLUETOOTH STATE

Toggle GPS


toggleGPS
()

API

Permission System

HANDLING A POTENTIAL ATTACK


Time
-
of
-
use system


Add a new runtime prompt for permission re
-
delegation



Install
-
time
system


Requester must statically ask for necessary permissions


Permission re
-
delegation is simply blocked at runtime



Relaxed install
-
time
system


Add prompts
just

for the case of permission re
-
delegation


23

DIFFERENT TYPES OF COMMUNICATION


Simplex communication
:
reduce recipient, not sender



Duplex communication
:
reduce both parties’ permissions



Request
-
reply
:
reduce recipient, not sender


Less strict than MAC, HBAC; same semantics as stack inspection


MAC
-
style: privileged requesters unable to accept responses;
would break apps

24

Application A

Requester

Application B

Deputy

Application A

Deputy

Application B

Deputy

Application A

Requester

Application B

Deputy

APPLICATION INSTANCES


Deputy might need to service user and multiple app
requesters simultaneously



Solution: create one instance per request


User interacts with primary
instance



When new interaction starts, create a new “application instance”


Each instance has its own set of current permissions


However, instances share app storage, etc.


25

IMPLEMENTATION


Android implementation


ServiceOS

(browser) implementation



Both are a few hundred lines of code



26

EVALUATION

Do we break applications
?

Do we stop attacks?

27

IMPACT ON DEPUTIES


Non
-
deputies


Do not need to be multiply instantiated


Do not experience privilege reduction



Unintentional deputies


IPC Inspection will prevent their misuse



Intentional deputies


Should add exception handling for failures


Install
-
time: should tell requesters what permissions they’ll need


28

IMPACT ON REQUESTERS


Time
-
of
-
use system:
no change



I
nstall
-
time system:
requesters need to add permissions


Requesters will
break

if they don’t add the necessary permissions


However, developers already have to add permissions for the API


Developers should notice any permission failures during testing


Deputies can help by declaring their requirements



Relaxed install
-
time system:
no change

29

BROKEN APPLICATIONS

Intentional Deputy

5 applications (25%)

Requester

6 applications (30%)

30

One application is both an intentional deputy and a requester

Developers
might

need to make changes to these applications:

Of those requesters:

2 of 6 requesters (10% of apps) need to add permissions

20 Android applications

EFFECTIVENESS AT ATTACK PREVENTION

31

Unintentional Deputy

4 applications (20%)

IPC Inspection prevents these from being exploited:

Also stops all the attacks on the built
-
in system applications

20 Android applications

CONCLUSION


Real world permission re
-
delegation vulnerabilities exist


A third of Android system applications contain permission re
-
delegation attacks



Future systems should be designed to prevent permission
re
-
delegation



IPC Inspection: an OS mechanism that prevents
permission re
-
delegation


Install
-
time: some requesters will need to add permissions



32

DEPUTIES THAT ATTENUATE AUTHORITY


In install
-
time systems, a situation can arise where:

Intentional deputy attenuates authority

This can lead to permission bloat

33

BeerCloud


INTERNET

System API

Barcode Scanner


CAMERA

getLabel
()

Camera.open
()

New permission model for least privilege permission
granting:


User
-
driven access control with access control
gadgets