2,196 research outputs found
Analyzing Android Browser Apps for file:// Vulnerabilities
Securing browsers in mobile devices is very challenging, because these
browser apps usually provide browsing services to other apps in the same
device. A malicious app installed in a device can potentially obtain sensitive
information through a browser app. In this paper, we identify four types of
attacks in Android, collectively known as FileCross, that exploits the
vulnerable file:// to obtain users' private files, such as cookies, bookmarks,
and browsing histories. We design an automated system to dynamically test 115
browser apps collected from Google Play and find that 64 of them are vulnerable
to the attacks. Among them are the popular Firefox, Baidu and Maxthon browsers,
and the more application-specific ones, including UC Browser HD for tablet
users, Wikipedia Browser, and Kids Safe Browser. A detailed analysis of these
browsers further shows that 26 browsers (23%) expose their browsing interfaces
unintentionally. In response to our reports, the developers concerned promptly
patched their browsers by forbidding file:// access to private file zones,
disabling JavaScript execution in file:// URLs, or even blocking external
file:// URLs. We employ the same system to validate the ten patches received
from the developers and find one still failing to block the vulnerability.Comment: The paper has been accepted by ISC'14 as a regular paper (see
https://daoyuan14.github.io/). This is a Technical Report version for
referenc
Talos: Neutralizing Vulnerabilities with Security Workarounds for Rapid Response
Considerable delays often exist between the discovery of a vulnerability and
the issue of a patch. One way to mitigate this window of vulnerability is to
use a configuration workaround, which prevents the vulnerable code from being
executed at the cost of some lost functionality -- but only if one is
available. Since program configurations are not specifically designed to
mitigate software vulnerabilities, we find that they only cover 25.2% of
vulnerabilities.
To minimize patch delay vulnerabilities and address the limitations of
configuration workarounds, we propose Security Workarounds for Rapid Response
(SWRRs), which are designed to neutralize security vulnerabilities in a timely,
secure, and unobtrusive manner. Similar to configuration workarounds, SWRRs
neutralize vulnerabilities by preventing vulnerable code from being executed at
the cost of some lost functionality. However, the key difference is that SWRRs
use existing error-handling code within programs, which enables them to be
mechanically inserted with minimal knowledge of the program and minimal
developer effort. This allows SWRRs to achieve high coverage while still being
fast and easy to deploy.
We have designed and implemented Talos, a system that mechanically
instruments SWRRs into a given program, and evaluate it on five popular Linux
server programs. We run exploits against 11 real-world software vulnerabilities
and show that SWRRs neutralize the vulnerabilities in all cases. Quantitative
measurements on 320 SWRRs indicate that SWRRs instrumented by Talos can
neutralize 75.1% of all potential vulnerabilities and incur a loss of
functionality similar to configuration workarounds in 71.3% of those cases. Our
overall conclusion is that automatically generated SWRRs can safely mitigate
2.1x more vulnerabilities, while only incurring a loss of functionality
comparable to that of traditional configuration workarounds.Comment: Published in Proceedings of the 37th IEEE Symposium on Security and
Privacy (Oakland 2016
A Critical Review of "Automatic Patch Generation Learned from Human-Written Patches": Essay on the Problem Statement and the Evaluation of Automatic Software Repair
At ICSE'2013, there was the first session ever dedicated to automatic program
repair. In this session, Kim et al. presented PAR, a novel template-based
approach for fixing Java bugs. We strongly disagree with key points of this
paper. Our critical review has two goals. First, we aim at explaining why we
disagree with Kim and colleagues and why the reasons behind this disagreement
are important for research on automatic software repair in general. Second, we
aim at contributing to the field with a clarification of the essential ideas
behind automatic software repair. In particular we discuss the main evaluation
criteria of automatic software repair: understandability, correctness and
completeness. We show that depending on how one sets up the repair scenario,
the evaluation goals may be contradictory. Eventually, we discuss the nature of
fix acceptability and its relation to the notion of software correctness.Comment: ICSE 2014, India (2014
Mapping and classification of ecologically sensitive marine habitats using unmanned aerial vehicle (UAV) imagery and object-based image analysis (OBIA)
Nowadays, emerging technologies, such as long-range transmitters, increasingly miniaturized components for positioning, and enhanced imaging sensors, have led to an upsurge in the availability of new ecological applications for remote sensing based on unmanned aerial vehicles (UAVs), sometimes referred to as “drones”. In fact, structure-from-motion (SfM) photogrammetry coupled with imagery acquired by UAVs offers a rapid and inexpensive tool to produce high-resolution orthomosaics, giving ecologists a new way for responsive, timely, and cost-effective monitoring of ecological processes. Here, we adopted a lightweight quadcopter as an aerial survey tool and object-based image analysis (OBIA) workflow to demonstrate the strength of such methods in producing very high spatial resolution maps of sensitive marine habitats. Therefore, three different coastal environments were mapped using the autonomous flight capability of a lightweight UAV equipped with a fully stabilized consumer-grade RGB digital camera. In particular we investigated a Posidonia oceanica seagrass meadow, a rocky coast with nurseries for juvenile fish, and two sandy areas showing biogenic reefs of Sabelleria alveolata. We adopted, for the first time, UAV-based raster thematic maps of these key coastal habitats, produced after OBIA classification, as a new method for fine-scale, low-cost, and time saving characterization of sensitive marine environments which may lead to a more effective and efficient monitoring and management of natural resource
Policy Enforcement with Proactive Libraries
Software libraries implement APIs that deliver reusable functionalities. To
correctly use these functionalities, software applications must satisfy certain
correctness policies, for instance policies about the order some API methods
can be invoked and about the values that can be used for the parameters. If
these policies are violated, applications may produce misbehaviors and failures
at runtime. Although this problem is general, applications that incorrectly use
API methods are more frequent in certain contexts. For instance, Android
provides a rich and rapidly evolving set of APIs that might be used incorrectly
by app developers who often implement and publish faulty apps in the
marketplaces. To mitigate this problem, we introduce the novel notion of
proactive library, which augments classic libraries with the capability of
proactively detecting and healing misuses at run- time. Proactive libraries
blend libraries with multiple proactive modules that collect data, check the
correctness policies of the libraries, and heal executions as soon as the
violation of a correctness policy is detected. The proactive modules can be
activated or deactivated at runtime by the users and can be implemented without
requiring any change to the original library and any knowledge about the
applications that may use the library. We evaluated proactive libraries in the
context of the Android ecosystem. Results show that proactive libraries can
automati- cally overcome several problems related to bad resource usage at the
cost of a small overhead.Comment: O. Riganelli, D. Micucci and L. Mariani, "Policy Enforcement with
Proactive Libraries" 2017 IEEE/ACM 12th International Symposium on Software
Engineering for Adaptive and Self-Managing Systems (SEAMS), Buenos Aires,
Argentina, 2017, pp. 182-19
An Empirical Study on Android-related Vulnerabilities
Mobile devices are used more and more in everyday life. They are our cameras,
wallets, and keys. Basically, they embed most of our private information in our
pocket. For this and other reasons, mobile devices, and in particular the
software that runs on them, are considered first-class citizens in the
software-vulnerabilities landscape. Several studies investigated the
software-vulnerabilities phenomenon in the context of mobile apps and, more in
general, mobile devices. Most of these studies focused on vulnerabilities that
could affect mobile apps, while just few investigated vulnerabilities affecting
the underlying platform on which mobile apps run: the Operating System (OS).
Also, these studies have been run on a very limited set of vulnerabilities.
In this paper we present the largest study at date investigating
Android-related vulnerabilities, with a specific focus on the ones affecting
the Android OS. In particular, we (i) define a detailed taxonomy of the types
of Android-related vulnerability; (ii) investigate the layers and subsystems
from the Android OS affected by vulnerabilities; and (iii) study the
survivability of vulnerabilities (i.e., the number of days between the
vulnerability introduction and its fixing). Our findings could help OS and apps
developers in focusing their verification & validation activities, and
researchers in building vulnerability detection tools tailored for the mobile
world
On the acceptance by code reviewers of candidate security patches suggested by Automated Program Repair tools
Background: Testing and validation of the semantic correctness of patches
provided by tools for Automated Program Repairs (APR) has received a lot of
attention. Yet, the eventual acceptance or rejection of suggested patches for
real world projects by humans patch reviewers has received a limited attention.
Objective: To address this issue, we plan to investigate whether (possibly
incorrect) security patches suggested by APR tools are recognized by human
reviewers. We also want to investigate whether knowing that a patch was
produced by an allegedly specialized tool does change the decision of human
reviewers. Method: In the first phase, using a balanced design, we propose to
human reviewers a combination of patches proposed by APR tools for different
vulnerabilities and ask reviewers to adopt or reject the proposed patches. In
the second phase, we tell participants that some of the proposed patches were
generated by security specialized tools (even if the tool was actually a
`normal' APR tool) and measure whether the human reviewers would change their
decision to adopt or reject a patch. Limitations: The experiment will be
conducted in an academic setting, and to maintain power, it will focus on a
limited sample of popular APR tools and popular vulnerability types
- …