3,108 research outputs found
Longitudinal Analysis of Android Ad Library Permissions
This paper investigates changes over time in the behavior of Android ad
libraries. Taking a sample of 100,000 apps, we extract and classify the ad
libraries. By considering the release dates of the applications that use a
specific ad library version, we estimate the release date for the library, and
thus build a chronological map of the permissions used by various ad libraries
over time. We find that the use of most permissions has increased over the last
several years, and that more libraries are able to use permissions that pose
particular risks to user privacy and security.Comment: Most 201
AdSplit: Separating smartphone advertising from applications
A wide variety of smartphone applications today rely on third-party
advertising services, which provide libraries that are linked into the hosting
application. This situation is undesirable for both the application author and
the advertiser. Advertising libraries require additional permissions, resulting
in additional permission requests to users. Likewise, a malicious application
could simulate the behavior of the advertising library, forging the user's
interaction and effectively stealing money from the advertiser. This paper
describes AdSplit, where we extended Android to allow an application and its
advertising to run as separate processes, under separate user-ids, eliminating
the need for applications to request permissions on behalf of their advertising
libraries.
We also leverage mechanisms from Quire to allow the remote server to validate
the authenticity of client-side behavior. In this paper, we quantify the degree
of permission bloat caused by advertising, with a study of thousands of
downloaded apps. AdSplit automatically recompiles apps to extract their ad
services, and we measure minimal runtime overhead. We also observe that most ad
libraries just embed an HTML widget within and describe how AdSplit can be
designed with this in mind to avoid any need for ads to have native code
Glider: A GPU Library Driver for Improved System Security
Legacy device drivers implement both device resource management and
isolation. This results in a large code base with a wide high-level interface
making the driver vulnerable to security attacks. This is particularly
problematic for increasingly popular accelerators like GPUs that have large,
complex drivers. We solve this problem with library drivers, a new driver
architecture. A library driver implements resource management as an untrusted
library in the application process address space, and implements isolation as a
kernel module that is smaller and has a narrower lower-level interface (i.e.,
closer to hardware) than a legacy driver. We articulate a set of device and
platform hardware properties that are required to retrofit a legacy driver into
a library driver. To demonstrate the feasibility and superiority of library
drivers, we present Glider, a library driver implementation for two GPUs of
popular brands, Radeon and Intel. Glider reduces the TCB size and attack
surface by about 35% and 84% respectively for a Radeon HD 6450 GPU and by about
38% and 90% respectively for an Intel Ivy Bridge GPU. Moreover, it incurs no
performance cost. Indeed, Glider outperforms a legacy driver for applications
requiring intensive interactions with the device driver, such as applications
using the OpenGL immediate mode API
Voting System Risk Assessment Via Computational Complexity Analysis
Any voting system must be designed to resist a variety of failures, ranging from inadvertent misconfiguration to intentional tampering. The problem with conducting analyses of these issues, particularly across widely divergent technologies, is that it is very difficult to make apples-to-apples comparisons. This paper considers the use of a standard technique used in the analysis of algorithms, namely complexity analysis with its big-O notation, which can provide a high-level abstraction that allows for direct comparisons across voting systems. We avoid the need for making unreliable estimates of the probability a system might be hacked or of the cost of bribing key players in the election process to assist in an attack. Instead, we will consider attacks from the perspective of how they scale with the size of an election. We distinguish attacks by whether they require effort proportional to the number of voters, effort proportional to the number of poll workers, or a constant amount of effort in order to influence every vote in a county. Attacks requiring proportionately less effort are correspondingly more powerful and thus require more attention to countermeasures and mitigation strategies. We perform this analysis on a variety of voting systems in their full procedural context, including optical scanned paper ballots, electronic voting systems, both with and without paper trails, Internet-based voting schemes, and future cryptographic techniques
Quire: Lightweight Provenance for Smart Phone Operating Systems
Smartphone apps often run with full privileges to access the network and
sensitive local resources, making it difficult for remote systems to have any
trust in the provenance of network connections they receive. Even within the
phone, different apps with different privileges can communicate with one
another, allowing one app to trick another into improperly exercising its
privileges (a Confused Deputy attack). In Quire, we engineered two new security
mechanisms into Android to address these issues. First, we track the call chain
of IPCs, allowing an app the choice of operating with the diminished privileges
of its callers or to act explicitly on its own behalf. Second, a lightweight
signature scheme allows any app to create a signed statement that can be
verified anywhere inside the phone. Both of these mechanisms are reflected in
network RPCs, allowing remote systems visibility into the state of the phone
when an RPC is made. We demonstrate the usefulness of Quire with two example
applications. We built an advertising service, running distinctly from the app
which wants to display ads, which can validate clicks passed to it from its
host. We also built a payment service, allowing an app to issue a request which
the payment service validates with the user. An app cannot not forge a payment
request by directly connecting to the remote server, nor can the local payment
service tamper with the request
- …