Download Android Security: A Case for Runtime Verification

Android Security: A Case for Runtime Verification
Hendra Gunadi
Alwen Tiu
School of Computer Science
The Australian National University
Canberra, Australia
School of Computer Engineering
Nanyang Technological University
Singapore
Abstract—Android is an operating system designed mainly for
mobile devices, such as smartphones and tablets. It accounts for
a large percentage of operating systems used in mobile devices
today, and it is increasingly targeted by malwares. In this paper,
we present an approach to improve Android security via runtime
verification. Our approach includes a custom reference monitor,
residing in the Linux kernel underlying the Android OS, that
enforces security policies written in a formal logical language
called linear temporal logic (LTL). LTL formulas are used to
specify malicious patterns of accesses, based on the history of
system events in Android. In a previous work, we described the
theoretical foundations underlying our monitoring framework
and its realization in a customized Android OS called LogicDroid.
Here we show a real case study demonstrating the effectiveness
of the additional security mechanism in LogicDroid in preventing
a previously unknown exploit to breach Android security. The
exploit allows an application to access certain critical functionalities of an Android phone, such as making phone calls,
terminating phone calls, and sending SMS, without having to ask
any permissions to do so, and thereby circumventing Android’s
security mechanism. LogicDroid, which was designed before the
exploit was known, was able to detect the use of this exploit and
was able to prevent it from accessing the said functionalities.
I. I NTRODUCTION
Android is an operating system for mobile devices such as
tablets and smartphones. It is currently estimated to have about
75% market share1 . It is also increasingly being targeted by
malwares, as shown by a recent study [1], where around one
million variants of malwares were detected in 2013.
The Android OS is built on top of Linux kernel, so at the
most basic level, it inherits most of the security architecture of
Unix/Linux. The architecture of Android is given in Figure 1.
Applications in Android, however, do not run directly on
Linux. Rather they run inside a virtual machine, called Dalvik
Virtual Machine (DVM), that are insulated from the rest of the
system. This method of sandboxing an application is similar
to the sandboxing implemented in Java virtual machine, but
does not include certain security features, such as the Security
Manager. This sandboxing and the Linux security features Android inherits address the traditional operating system security
issues. However, most of the interesting issues arise on the
level of applications, and a separate security mechanism is
required to deal with those.
The Android application framework provides several API
to access certain functionalities of the device, such as making
1 Source:
IDC Mobile Phone tracker 2013
Fig. 1: Android OS architecture. Image source: Wikipedia.
phone calls, sending SMS, querying GPS location information, or unique device ID (such as the IMEI number), etc.
Access to these functionalities is controlled via the permission
mechanism of Android. For each functionality of interests,
Android associates a unique permission required to access
that functionality. For example, to be able to connect to the
internet, an app in Android needs to have the INTERNET
permission. Similarly, to access fine location information (such
as that obtained through a GPS device), an app needs to
have the ACCESS FINE LOCATION permission. For a list of
permissions in Android, the reader is referred to the Android
developer website.2 . Permissions are explicitly requested by
an app at installation time. But once they are granted, the app
does not need to request them anymore everytime it wants
to access the functionalities associated with the permissions.
Permissions granted to an app cannot be revoked without
uninstalling the app.
Despite all the security mechanisms mentioned above, Android is still vulnerable to various attacks. We shall focus
mostly on attacks that target the permission mechanism at the
application level. A main weakness in the Android permission
mechanism lies in the so-called permission leakage problem [2]. In Android, an app can provide a “service” to another
app. Through this provision of services, an app can “leak”
2 http://developer.android.com
certain capabilities to an unprivileged app. For example, an app
which has access to the ability to make phone call could act as
a proxy for another app. This leads to the problem of privilege
escalation, i.e., an app obtains a permission it was not granted
by exploiting other apps. A recent study [2] on major brands
of Android phones shows that there are a number of built-in
apps that ship with the phones that expose critical interfaces
without any permission enforcements that can be exploited to
perform privilege escalation attack. Even assuming all these
interfaces are properly guarded, there still exist simple exploits
that cannot be easily fixed, simply because it will affect users
experience significantly. For example, by default, in Android
any app can launch the default browser without requiring
any permission. With some work, a malicious app can be
developed to launch a browser undetected (e.g., when the
device screen is off) to leak sensitive data, as demonstrated
in [3].
There are two types of attacks that can lead to privilege
escalation [4]: the confused deputy attack and the collusion
attack. In the confused deputy attack, a legitimate app (the
deputy) has permissions to certain services, e.g., sending SMS,
and exposes an interface to this functionality without any
guards. This interface can then be exploited by a malicious
app to send SMS, even though the malicious app does not
have the permission, as shown in [3], [2], [5]. The collusion
attack requires two or more malicious apps to collaborate. The
rational behind this attack is that each app only requests a
strict subset of the set of permissions to execute the attack
(so as not to alarm the user, or to avoid static checkers) but
combined together they will have all the required permissions. A proof-of-concept malware with such properties, called
SoundComber [6], has been constructed.
In this paper we present a security extension to Android,
called LogicDroid, that uses techniques from runtime verification to enhance Android security. Our framework focuses on the problem of privilege escalation, although it is
generic enough to impose other security requirements. The
framework monitors communication between apps and other
system events, and decide, via an inference engine residing in
a reference monitor inside the Linux kernel, whether policy
violation occurs or not, and if so, what actions need to be
taken. We are using runtime verification techniques derived
from formal logic, in particular, from linear temporal logic [7].
In a previous work [8], we have detailed the theoretical
foundations of our runtime verification approach. Here we
describe in more detail the implementation of the runtime
security monitor of LogicDroid, and demonstrates a case
study to show the effectiveness of our framework in detecting
privilege escalation resulting from a previously unknown bugs
in the Android application framework.
The rest of the paper is organized as follows: In Section II
we give an overview of the foundations of the runtime
verification framework in LogicDroid. In Section III, we
present the architecture of LogicDroid and detail some of
its implementation, in particular those related to detection
of access attempts to certain functionalities guarded by per-
missions. In Section IV, we give details of the exploit in
the Android component com.android.phone that leads
to privilege escalation, and how LogicDroid mitigates this
exploit. Section V concludes the paper, discusses some related
work and future directions.
II. RUNTIME VERIFICATION USING L INEAR T EMPORAL
L OGIC
At the core of runtime verification is a reference monitor
that guards access to certain objects in the (operating) system
that a system owner would like to protect from unauthorized
uses. In the context of Android, these resources could be
access to private data such as contact database, location
information, or functionalities such as the ability to make
phone calls, SMS or opening a connection to the internet. A
runtime verification framework should allow one to specifiy
unambigiously the security policy to be implemented, and
an enforcement mechanism for that policy. In this work, we
follow an established approach to runtime verification using
linear temporal logic (LTL) [7]. Linear temporal logic extends
the (classical) propositional logic with temporal operators that
allow one to specify temporal relations between events in
a system, something which is crucial in detecting malware
behaviours in Android. One of the advantages of specifying
security policies in LTL is that policy enforcement becomes
an instance of the model checking problem [9], which has
been extensively studied in the literature and many results are
already known and can be reused.
For our purpose, we need to extend LTL with two additional
features. One is the addition of metric operators, which allow
one to specify exact time interval between events. The other
is the addition of recursive definitions, which allow one to
specify recursive patterns of events. One such pattern that we
shall be looking at is the transitivity of system calls, i.e., we
would like to be able to specify a call chain between two
apps, possibly making use of other intermediate apps. Such
call patterns are an ingredient in detecting privilege escalation
attacks, as we shall see. The logic resulting from adding
these two features to LTL is called RMTL (for ’recursive
metric temporal logic’). In the following, we shall give a brief
overview of this logic and some of its operators. The details
of the syntax and the semantics of this logic, along with its
algorithmic properties, can be found in [8].
Formulas in RMTL extends those of first-order logic (also
called predicate logic in the literature) with temporal operators.
As in first-order logic, formulas in RMTL contain predicates,
which are essentially relations over certain objects. For example, objects in our setting could be an app, a permission
such as READ PHONE STATE, CALL PRIVILEGED, etc.
An example of a predicate could be one describing a state of
an app, such as an app being a system app, or an inter-process
communication event, where an app A sends a message to app
B. For the current paper, we shall be using simple predicates
such as the following:
● system(x): This denotes the fact that x is a system app,
i.e., an app that comes pre-installed with the phone and
is generally provided by the phone manufacturer.
hasCallP rivilegedP ermission(y): app y has the
CALL PRIVILEGED permission. For each permission in Android, we have a similar predicate for
that permission. For example, we could also add
hasInternetP ermission(y) to denote that y has the
INTERNET permission, etc.
● call(x, y): this denotes the event that app x makes an IPC
call to app y, e.g., this could be a result of x sending an
Intent object to y, or just a direct call via the Binder
IPC mechanism underlying the Android framework.
Formally, the formulas of RMTL are defined via the following grammar:
●
F ∶= – ∣ p(t1 , . . . , tm ) ∣ P (t1 , . . . , tn ) ∣
F ∨ F ∣ ¬F ∣
●F ∣ F S F ∣ ⧫F ∣ ⟐F ∣
●n F ∣ F Sn F ∣ ⧫n F ∣ ⟐n F ∣ ∃x.F
where m and n are natural numbers. The formula – denotes
falsehood. The formula p(t1 , . . . , tm ) denotes a predicate
that takes m arguments. The operators ∨, ¬, ∃ correspond
to disjunction, negation and the existential quantifier from
first-order logic. Some operators are not given explicitly as
they can be defined using the connectives given above, e.g.,
conjunction can be expressed via negation and disjunction. The
formula P (t1 , . . . , tn ) denotes a recursively defined predicate
(or recursive predicates for short); we shall come back to this
later. The rest of the operators are specific to temporal logic.
The index n in some operators, e.g., A Sn B, denotes the
time interval [0, n). Note that we consider only discrete time
here. We shall not give the detailed meaning of each operator
since this is not the focus of this paper. Rather we shall give
an intuitive explanation of some operators to give the reader
a flavour of the formal model underlying RMTL. Technical
details of RMTL are available in [8].
Formulas of RMTL are interpreted in a semantic model
which consists of a sequence of events, temporally ordered.
In LTL, one is only concerned with the relative ordering of
events, but not the exact time and date an event occurred. So
one can talk about event A occurring before event B, but not
that event A occured at a specific time, or within a specific
interval of time from event B. Graphically, the semantic model
of RMTL can be presented as follows:
Timestamps of events
t1
t2
t3
t4
t5
t6
E1
E2
E3
E4
E5
E6
that event. Given such a model, we can then specify certain
relations between events in the timeline, from the perspective
of a particular time point (e.g., the present time). The operators
of RMTL provides the building blocks to specify a rich
collection of patterns of relations one can specify. We give
a couple of examples next.
For the first example, consider the formula ⟐50 D. Intuitively, this formula states that event D was observed sometime
in the past within 50 time units from the presence. Graphically,
Temporal
Operators
this is illustrated as
follows:
10:30
10:35
11:00
A
B
D
11:05
C
11:30
11:35
C
C
Current time point
(the present)
Temporal operators alone are not enough to specify some
recursive
patterns
needed
to capture
For
B must
happen
sometime,
within 50privilege
seconds, inescalation.
the
future.
example,
consider a sequence of IPC calls, as represented in
the following model:
Recursive Patterns
10:30
10:35
call(a,b)
call(b,c)
10:38
call(c,d)
10:47
E
11:30
11:35
F
G
How do we express the pattern that there is a chain of IPC
In this case,
there
calleach
chain,
starting within
from 10
a and
ending
calls from
a toisd,aand
call happened
seconds?
in d, such that each successive call happened within 10 time
The policy language needs to support recursion.
units. One can imagine a generalization of this case to an
arbitrary number of successive calls that are chained together.
To deal with such a possibility, we introduce a notion of
recursive definition. In this case, we create a new predicate,
called trans, that effectively defines the transitive closure of
the call events. This can be expressed in RMTL as follows:
trans(x, y) ∶= call(x, y) ∨ ∃z. ⟐n trans(x, z) ∧ call(z, y)
where n is a time interval. Intuitively, this definition of
trans(x, y) says that there is a call chain from x to y if and
only if either x calls y directly, or there is a call chain from
x to some z, and there is a direct call from z to y.
The presence of recursive definitions and temporal operators
allows us to write complex formulas that can capture various
access control policies; see [8] for more examples.
III. L OGIC D ROID : OVERVIEW OF ARCHITECTURE AND
…………..
System generated events
Each dot represents a time point in the time line. At each
time point, we keep two kinds of information: the event that
takes place at that particular time point, and the timestamp of
IMPLEMENTATION
We now describe our modification to the Android OS,
called LogicDroid. At the heart of LogicDroid is a reference
monitor that enforces security policies specified in RMTL.
As is common in a runtime verification framework [10],
there is a part of the framework which deals with detection
of events, and there is another part which deals with the
enforcement of policies. In our case, there is a third part
which deals with automated generation of monitors. We give
a brief overview of our implementation; details of the monitor
code generators and the modified Android OS are available
from http://github.com/h3nd24. We use Android 4.1.1 r6 as
the base for our modified Android OS. We have tested our
implementation in both Android emulator and an actual device
(Samsung Galaxy Nexus phone).
The LogicDroid architecture is given in Figure 2. The
detection of events is done via various “hooks” into the
Android OS; these include hooks in the framework layer,
system library and the Linux kernel itself. Events intercepted,
such as requests to resources by an app, are forwarded to the
reference monitor for further evaluation. We will discuss some
implementations of the hooks below. The reference monitor
resides in the Linux kernel underlying the Android OS. It
processes events as they come, and for each new event, it
checks whether the new event, together with the history of
events processed so far, violates the current security policy.
Note that our security checking mechanisms are implemented
on top of the Android permission mechanism, so in the case
where our reference monitor does nothing, the default Android
permission mechanism would still be enforced.
The current security policy to be enforced is hardcoded
in the monitor for efficiency reasons. This, however, makes
it slightly complicated to update the security policy in the
monitor. We need to provide a facility to update security
policies since this might be required to counter new forms
of attacks that may not be handled by the current policy. Our
current approach is to design the monitor as a kernel module;
this allows it to be removed and reinstalled in a live system. We
then devise an offline monitor generation process. The monitor
generator takes as input a security policy (specified in RMTL,
using XML as the representation language) and generates C
codes that correspond to the kernel module of the policy. This
appears to be a good compromise between performance and
security.
The algorithm for detection of violation of policies implemented in the reference monitor is described in detail in
[8]. Here we focus on the detection of events, which are
obtained by placing various hooks in the Android OS. Android
sandboxing places a restriction on how apps can communicate.
Communication between apps are typically done through the
so-called Intent objects in the Android framework. It is essentially a form of inter process communication (IPC) mechanism
specific to Android. At the application level, leakeage of
permissions can often be tracked by tracking the passing of
Intent objects, so our framework tracks this kind of intents
objects to infer privilege escalation. The most time consuming
part of our implementation was actually in tracing how Intent
objects are processed, and in figuring out where to put the
hooks to be most effective in intercepting requests to resources.
a) The phone call hook: In general, resources in Android that are protected by the Android permission mechanism are located in the framework level. One such resource is to ability to make phone calls. In the source
code of Android, this functionality is located in the
Offline monitor
generation
Security
Policy
XML doc
Monitor
generator
C codes
C Compiler
Binaries of kernel modules
Fig. 2: The architecture of LogicDroid
Fig. 3: A hook in the Android framework to intercept phone
calls
OutgoingCallBroadcaster.java file. This file is
compiled into a component, and when an app wants to make
a phone call, it will need to send an Intent object to this
component. Interception of the phone call request can be done
in this component. Figure 3 shows a snipet of the codes where
the permission checked is done. The hook is placed just before
the Android permission checks take place.
b) The socket hook: This hook is used to detect an
attempt to connect to a network (or internet) by opening a
socket. Intercepting the attempts to connect to the internet or
a local network proves to be quite tricky. Although there are
components in the Android framework that provide internet
related services, such as HTTP protocol, an app can by pass
these components entirely and simply makes a system call to
open sockets directly. Thus to intercept this connection, we
need to place the hook in the Linux kernel. In Android, any
app who wants to connect to a network needs to have the IN-
Fig. 4: A hook placed in the Linux kernel to intercept calls to
network sockets
TERNET permission. This permission is checked in the kernel
when an app tries to open a socket. This is enforced through
Linux access control, i.e., the network socket connection is
associated with a particular group called INTERNET. Only
applications (users) belonging to this group will be able to
open a socket. Practically, when an application asks for the
INTERNET permission during installation, it will be added as
a member of the the “INTERNET” group. The hook for socket
is placed in the socket.c file (from the Linux kernel soure).
The extra security checking done by LogicDroid is the same
in this case, i.e., it will consult our custom monitor before
returning to the normal execution flow. The snipet of codes
and where to place the hook is shown in Figure 4
IV. V ULNERABILITIES IN COM . ANDROID . PHONE
COMPONENT
We now discuss how the added security mechanism of
LogicDroid allows us to prevent apps from exploiting recently
discovered vulnerabilities in the com.android.phone component in the Android framework. We would like to emphasize
that the LogicDroid security mechanism was designed before
the discovery of the vulnerabilities and it was not designed
specifically to counter those vulnerabilities. The fact that it
works shows the benefit of runtime verification in general,
and our security extension in particular.
The vulnerabilities in question were first made public by
CureSec.com on 4th July 2014, although the vulnerabilities
themselves were known to them in late 2013. The fragment
of codes that contains these vulnerabilities is shown in Figure 5. These vulnerabilities are also known as “CVE-20136272 com.android.phone” in the database of vulnerabilties
maintained by the MITRE Corporation.
The bugs in the codes in Figure 5 are essentially a privilege
escalation bug in Android official component that enables a
user to do three privileged actions without having the privilege
to do so, namely, sending SMS, making unresticted phone
Fig. 5: Vulnerabilities in the android.com.phone component.
calls, and terminating on-going calls. The second bug allows
a user to essentially gains the CALL PRIVILEGED permission through the system component com.android.phone.
Android documentation states that the CALL PRIVILGED
permission “allows an application to call any phone number,
including emergency numbers, without going through the
Dialer user interface for the user to confirm the call being
placed.” Thus the bug would allow a malicious app to call
any number in a stealth mode without notifying the user nor
requiring the user’s actions. This is the more interesting bug
of the tree mentioned above, so we used this as a case study
to test the effectiveness of LogicDroid.
The bug is caused by a broadcast receiver component
in PhoneApp.java in the Android framework (different
versions of Android may have this in different file). To be
precise, the name of the component is NotificationBroadcastReceiver. The component listen to the intents broadcast
by apps, and upon receiving an intent, if the action of the
intent is ACTION CALL BACK FROM NOTIFICATION,
then this component will start the activity that can handle
CALL PRIVILEGED. See the highlighted parts in Figure 5.
Privilege escalation occurs in this setting because the component that broadcast the intent in the first place does not
necessarily have the permission to do CALL PRIVILEGED,
and the receiving component in Phone.java does not enforce that the caller must have the right permission. This is a
typical confused deputy attack we mentioned earlier.
Thus a general security policy that prevents privilege escalation would stop the exploit. Such a policy is specified in
LogicDroid as the following RMTL formula:
∃x
(trans(x, CALL PRIVILEGED) ∧ ¬system(x)
∧hasCallP rivilegedP ermission(x))
where the trans predicate is as defined earlier in Section II.
In general, LogicDroid supports such policies for detecting
indirect access to a sink, i.e., a particular permission we
would like to protect, such as INTERNET, READ CONTACT,
SEND SMS, etc. Note that a policy in LogicDroid specifies
the patterns that are not allowed in the system calls. In this
case, the policy indicates that a forbidden access pattern is one
in which there is an indirect call from a non-system application
x with no CALL PRIVILEGED permission to the sink that
handles the CALL PRIVILEGED.
We have tested our runtime monitor against this particular exploit. CureSec provides a prove-of-concept app (called
“Kolme”) that demonstrates this exploit (see ). We ran this
app inside our modified Android, which is still at version
4.1.1, and so still contains the vulnerable codes. LogicDroid
successfully detected the attempt by Kolme app to gain
CALL PRIVILEGED permission and stops the attempt.
V. C ONCLUSION AND FUTURE WORK
We have outlined a new runtime monitoring framework
for the Android operating system that builds on the wellestablished techniques for runtime verification from linear
temporal logic. The framework has been implemented on top
of a version of Android, and has been tested both on the
emulator and an actual device. Our framework is modular,
in the sense that security policies that the monitor enforces
can be added and removed without having to change the
entire implementation. The use of a logical language, the logic
RMTL, allows one to specify a security policy at a high
level of abstraction, and yet at the same time benefit from
our techniques for automatically generating actual implementations of the monitor from the specification. To demonstrate
the effectiveness of our framework, we demonstrate how it prevents a previously unknown exploit in the system component
com.android.phone to gain privileges.
Android security has recently attracted a lot of attention
from the research community. Our framework is one of several
that propose some kind of security extensions to the Android
OS. A brief survey of existing work in this area can be found
in [4]. Here we mention only three related work that are most
relevant to our approach.
The QUIRE [11] extension to Android is an applicationcentric approach to privilege escalation, rather than the systemcentric approach as in our case. QUIRE detects privilege
escalation by tagging the intent objects with the caller’s unique
user id. An app that receives the intent can thus check the
original source of the call, and can enforce the required
permissions on the original caller. This is thus more of a
discretionary access control, imposed by an individual app that
receives the call, whereas our approach is more of a mandatory
access control that applies system wide. This extension would
not be able to prevent the com.android.phone because
the receiving app that processes the intents need to enforce
the required permissions. In this case the exploit cannot
be prevented simply because the receiving component in
com.android.phone does not impose any requirements
on the calling app.
IPC Inspection [12] is a system-centric security extension to
Android. Unlike QUIRE, it does not rely on a particular app
(the intent receiver) to check for the permissions of the original
caller. Rather it works by reducing the privilege of the callee,
depending on the privileges of the original caller. If the original
caller does not have, say, permission to CALL PRIVILEGED,
then this permission would be temporarily revoked from the
callee when the call takes place. This in principle could also
prevent the com.android.phone exploit, although as far
as we know this has not yet been confirmed.
XManDroid [4] is another system-centric extension to Android, and is perhaps the closest to our work. It features a
security monitor that maintains maintains a call graph between
apps to detect privilege esclation. The main difference seems
mainly in the policy language used to specify security policies.
Our framework is more modular in the sense that we do not
fix the implementation of the monitor to a particular policy.
For example, our mechanism for detecting transitivity of calls
does not rely on a specific data structure (e.g., a call graph as
in XManDroid), but rather the codes implementing this kind of
privilege escalation is generated automatically from the RMTL
specification.
Future work: We are investigating extensions of RMTL
with operators that would allow one to specify certain aggregate properties [13], such as counting the number of policy
violations, or specifying other statistical patterns in event
history for deciding policy enforcement.
R EFERENCES
[1] G. Abendan, “Mobile malware, high risks apps hit 1M mark,” TrendMicro Security Lab Blog, September 2013.
[2] M. Grace, Y. Zhou, Z. Wang, and X. Jiang, “Systematic detection of
capability leaks in stock android smartphones,” in NDSS12, 2012.
[3] A. Lineberry, D. L. Richardson, and T. Wyatt, “These aren’t the
permissions you’re looking for,” in DefCon 18, 2010.
[4] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer, A.-R. Sadeghi, and
B. Shastry, “Towards taming privilege-escalation attacks on android,”
in NDSS12, 2012.
[5] P. P. F. Chan, L. C. K. Hui, and S.-M. Yiu, “Droidchecker: analyzing
android applications for capability leak,” in WISEC. ACM, 2012, pp.
125–136.
[6] R. Schlegel, K. Zhang, X. Zhou, M. Intwala, A. Kapadia, and X. Wang,
“Soundcomber: A stealthy and context-aware sound trojan for smartphones,” in 18th Annual Network and Distributed System Security
Symposium (NDSS), 2011.
[7] A. Pnueli, “The temporal logic of programs,” in FOCS. IEEE Computer
Society, 1977, pp. 46–57.
[8] H. Gunadi and A. Tiu, “Efficient runtime monitoring with metric
temporal logic: A case study in the android operating system,” in FM
2014, ser. Lecture Notes in Computer Science, vol. 8442, 2014, pp.
296–311.
[9] D. P. Edmund Clarke, Orna Grumberg, Model Checking. MIT Press,
2001.
[10] B. A. Schroeder, “On-line monitoring: A tutorial,” Computer,
vol. 28, no. 6, pp. 72–78, Jun. 1995. [Online]. Available: http:
//dx.doi.org/10.1109/2.386988
[11] M. Dietz, S. Shekhar, Y. Pisetsky, A. Shu, and D. S. Wallach, “Quire:
Lightweight provenance for smartphone operating systems,” in 20th
USENIX Security Symposium, 2011.
[12] A. P. Felt, H. Wang, A. Moschuk, S. Hanna, and E. Chin, “Permission redelegation: Attacks and defenses,” in 20th USENIX Security Symposium,
2011.
[13] D. A. Basin, F. Klaedtke, S. Marinovic, and E. Zalinescu, “Monitoring
of temporal first-order properties with aggregations,” in RV, ser. Lecture
Notes in Computer Science, vol. 8174, 2013, pp. 40–58.