2,258 research outputs found
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
Vulnerable Open Source Dependencies: Counting Those That Matter
BACKGROUND: Vulnerable dependencies are a known problem in today's
open-source software ecosystems because OSS libraries are highly interconnected
and developers do not always update their dependencies. AIMS: In this paper we
aim to present a precise methodology, that combines the code-based analysis of
patches with information on build, test, update dates, and group extracted from
the very code repository, and therefore, caters to the needs of industrial
practice for correct allocation of development and audit resources. METHOD: To
understand the industrial impact of the proposed methodology, we considered the
200 most popular OSS Java libraries used by SAP in its own software. Our
analysis included 10905 distinct GAVs (group, artifact, version) when
considering all the library versions. RESULTS: We found that about 20% of the
dependencies affected by a known vulnerability are not deployed, and therefore,
they do not represent a danger to the analyzed library because they cannot be
exploited in practice. Developers of the analyzed libraries are able to fix
(and actually responsible for) 82% of the deployed vulnerable dependencies. The
vast majority (81%) of vulnerable dependencies may be fixed by simply updating
to a new version, while 1% of the vulnerable dependencies in our sample are
halted, and therefore, potentially require a costly mitigation strategy.
CONCLUSIONS: Our case study shows that the correct counting allows software
development companies to receive actionable information about their library
dependencies, and therefore, correctly allocate costly development and audit
resources, which is spent inefficiently in case of distorted measurements.Comment: This is a pre-print of the paper that appears, with the same title,
in the proceedings of the 12th International Symposium on Empirical Software
Engineering and Measurement, 201
How Effective Are Neural Networks for Fixing Security Vulnerabilities
Security vulnerability repair is a difficult task that is in dire need of
automation. Two groups of techniques have shown promise: (1) large code
language models (LLMs) that have been pre-trained on source code for tasks such
as code completion, and (2) automated program repair (APR) techniques that use
deep learning (DL) models to automatically fix software bugs.
This paper is the first to study and compare Java vulnerability repair
capabilities of LLMs and DL-based APR models. The contributions include that we
(1) apply and evaluate five LLMs (Codex, CodeGen, CodeT5, PLBART and InCoder),
four fine-tuned LLMs, and four DL-based APR techniques on two real-world Java
vulnerability benchmarks (Vul4J and VJBench), (2) design code transformations
to address the training and test data overlapping threat to Codex, (3) create a
new Java vulnerability repair benchmark VJBench, and its transformed version
VJBench-trans and (4) evaluate LLMs and APR techniques on the transformed
vulnerabilities in VJBench-trans.
Our findings include that (1) existing LLMs and APR models fix very few Java
vulnerabilities. Codex fixes 10.2 (20.4%), the most number of vulnerabilities.
(2) Fine-tuning with general APR data improves LLMs' vulnerability-fixing
capabilities. (3) Our new VJBench reveals that LLMs and APR models fail to fix
many Common Weakness Enumeration (CWE) types, such as CWE-325 Missing
cryptographic step and CWE-444 HTTP request smuggling. (4) Codex still fixes
8.3 transformed vulnerabilities, outperforming all the other LLMs and APR
models on transformed vulnerabilities. The results call for innovations to
enhance automated Java vulnerability repair such as creating larger
vulnerability repair training data, tuning LLMs with such data, and applying
code simplification transformation to facilitate vulnerability repair.Comment: This paper has been accepted to appear in the proceedings of the 32nd
ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA
2023), and to be presented at the conference, that will be held in Seattle,
USA, 17-21 July 202
Impact assessment for vulnerabilities in open-source software libraries
Software applications integrate more and more open-source software (OSS) to
benefit from code reuse. As a drawback, each vulnerability discovered in
bundled OSS potentially affects the application. Upon the disclosure of every
new vulnerability, the application vendor has to decide whether it is
exploitable in his particular usage context, hence, whether users require an
urgent application patch containing a non-vulnerable version of the OSS.
Current decision making is mostly based on high-level vulnerability
descriptions and expert knowledge, thus, effort intense and error prone. This
paper proposes a pragmatic approach to facilitate the impact assessment,
describes a proof-of-concept for Java, and examines one example vulnerability
as case study. The approach is independent from specific kinds of
vulnerabilities or programming languages and can deliver immediate results
Automatic Software Repair: a Bibliography
This article presents a survey on automatic software repair. Automatic
software repair consists of automatically finding a solution to software bugs
without human intervention. This article considers all kinds of repairs. First,
it discusses behavioral repair where test suites, contracts, models, and
crashing inputs are taken as oracle. Second, it discusses state repair, also
known as runtime repair or runtime recovery, with techniques such as checkpoint
and restart, reconfiguration, and invariant restoration. The uniqueness of this
article is that it spans the research communities that contribute to this body
of knowledge: software engineering, dependability, operating systems,
programming languages, and security. It provides a novel and structured
overview of the diversity of bug oracles and repair operators used in the
literature
ACMiner: Extraction and Analysis of Authorization Checks in Android's Middleware
Billions of users rely on the security of the Android platform to protect
phones, tablets, and many different types of consumer electronics. While
Android's permission model is well studied, the enforcement of the protection
policy has received relatively little attention. Much of this enforcement is
spread across system services, taking the form of hard-coded checks within
their implementations. In this paper, we propose Authorization Check Miner
(ACMiner), a framework for evaluating the correctness of Android's access
control enforcement through consistency analysis of authorization checks.
ACMiner combines program and text analysis techniques to generate a rich set of
authorization checks, mines the corresponding protection policy for each
service entry point, and uses association rule mining at a service granularity
to identify inconsistencies that may correspond to vulnerabilities. We used
ACMiner to study the AOSP version of Android 7.1.1 to identify 28
vulnerabilities relating to missing authorization checks. In doing so, we
demonstrate ACMiner's ability to help domain experts process thousands of
authorization checks scattered across millions of lines of code
Do not trust me: Using malicious IdPs for analyzing and attacking Single Sign-On
Single Sign-On (SSO) systems simplify login procedures by using an an
Identity Provider (IdP) to issue authentication tokens which can be consumed by
Service Providers (SPs). Traditionally, IdPs are modeled as trusted third
parties. This is reasonable for SSO systems like Kerberos, MS Passport and
SAML, where each SP explicitely specifies which IdP he trusts. However, in open
systems like OpenID and OpenID Connect, each user may set up his own IdP, and a
discovery phase is added to the protocol flow. Thus it is easy for an attacker
to set up its own IdP. In this paper we use a novel approach for analyzing SSO
authentication schemes by introducing a malicious IdP. With this approach we
evaluate one of the most popular and widely deployed SSO protocols - OpenID. We
found four novel attack classes on OpenID, which were not covered by previous
research, and show their applicability to real-life implementations. As a
result, we were able to compromise 11 out of 16 existing OpenID implementations
like Sourceforge, Drupal and ownCloud. We automated discovery of these attacks
in a open source tool OpenID Attacker, which additionally allows fine-granular
testing of all parameters in OpenID implementations. Our research helps to
better understand the message flow in the OpenID protocol, trust assumptions in
the different components of the system, and implementation issues in OpenID
components. It is applicable to other SSO systems like OpenID Connect and SAML.
All OpenID implementations have been informed about their vulnerabilities and
we supported them in fixing the issues
STATIC CODE ANALYSIS
A lot of the defects that are present in a program are not visible to the compiler. Static code analysis is a way to find bugs and reduce the defects in a software application. This paper gives you an overview on static code analysis, well-known tools and the benefits of this practice.code, analysis
Time for Addressing Software Security Issues: Prediction Models and Impacting Factors
Finding and fixing software vulnerabilities have become a major struggle for most software development companies. While generally without alternative, such fixing efforts are a major cost factor, which is why companies have a vital interest in focusing their secure software development activities such that they obtain an optimal return on this investment. We investigate, in this paper, quantitatively the major factors that impact the time it takes to fix a given security issue based on data collected automatically within SAP’s secure development process, and we show how the issue fix time could be used to monitor the fixing process. We use three machine learning methods and evaluate their predictive power in predicting the time to fix issues. Interestingly, the models indicate that vulnerability type has less dominant impact on issue fix time than previously believed. The time it takes to fix an issue instead seems much more related to the component in which the potential vulnerability resides, the project related to the issue, the development groups that address the issue, and the closeness of the software release date. This indicates that the software structure, the fixing processes, and the development groups are the dominant factors that impact the time spent to address security issues. SAP can use the models to implement a continuous improvement of its secure software development process and to measure the impact of individual improvements. The development teams at SAP develop different types of software, adopt different internal development processes, use different programming languages and platforms, and are located in different cities and countries. Other organizations, may use the results—with precaution—and be learning organizations
- …