Biblio

Concurrency vulnerabilities caused by synchronization problems will occur in the execution of multi-threaded programs, and the emergence of concurrency vulnerabilities often cause great threats to the system. Once the concurrency vulnerabilities are exploited, the system will suffer various attacks, seriously affecting its availability, confidentiality and security. In this paper, we extract 839 concurrency vulnerabilities from Common Vulnerabilities and Exposures (CVE), and conduct a comprehensive analysis of the trend, classifications, causes, severity, and impact. Finally, we obtained some findings: 1) From 1999 to 2021, the number of concurrency vulnerabilities disclosures show an overall upward trend. 2) In the distribution of concurrency vulnerability, race condition accounts for the largest proportion. 3) The overall severity of concurrency vulnerabilities is medium risk. 4) The number of concurrency vulnerabilities that can be exploited for local access and network access is almost equal, and nearly half of the concurrency vulnerabilities (377/839) can be accessed remotely. 5) The access complexity of 571 concurrency vulnerabilities is medium, and the number of concurrency vulnerabilities with high or low access complexity is almost equal. The results obtained through the empirical study can provide more support and guidance for research in the field of concurrency vulnerabilities.

Static analysis tools generate a large number of alarms that require manual inspection. In prior work, repositioning of alarms is proposed to (1) merge multiple similar alarms together and replace them by a fewer alarms, and (2) report alarms as close as possible to the causes for their generation. The premise is that the proposed merging and repositioning of alarms will reduce the manual inspection effort. To evaluate the premise, this paper presents an empirical study with 249 developers on the proposed merging and repositioning of static alarms. The study is conducted using static analysis alarms generated on \$C\$ programs, where the alarms are representative of the merging vs. non-merging and repositioning vs. non-repositioning situations in real-life code. Developers were asked to manually inspect and determine whether assertions added corresponding to alarms in \$C\$ code hold. Additionally, two spatial cognitive tests are also done to determine relationship in performance. The empirical evaluation results indicate that, in contrast to expectations, there was no evidence that merging and repositioning of alarms reduces manual inspection effort or improves the inspection accuracy (at times a negative impact was found). Results on cognitive abilities correlated with comprehension and alarm inspection accuracy.

Automatic Static Analysis Tools (ASATs) detect coding rule violations, including mistakes and bad practices that frequently occur during programming. While ASATs are widely used in both OSS and industry, the developers do not resolve more than 80% of the detected violations. As one of the reasons, most ASATs users do not customize their ASATs to their projects after installation; the ASATs with the default configuration report many rule violations that confuse developers. To reduce the ratio of such uninteresting warning messages, we propose a method to customize ASATs according to the product source code automatically. Our fundamental hypothesis is: A software project has interesting ASAT rules that are consistent over time. Our method takes source code as input and generates an ASAT configuration. In particular, the method enables optional (i.e., disabled by default) rules that detected no violations on the version because developers are likely to follow the rules in future development. Our method also disables violated rules because developers were unlikely to follow them. To evaluate the method, we applied our method to 643 versions of four JavaScript projects. The generated configurations for all four projects increased the ASAT precision. They also increased recall for two projects. The result shows that our method helps developers to focus on their attractive rule violations. Our implementation of the proposed method is available at https://github.com/devreplay/linter-maintainer

Discovering vulnerabilities is an information-intensive task that requires a developer to locate the defects in the code that have security implications. The task is difficult due to the growing code complexity and some developer's lack of security expertise. Although tools have been created to ease the difficulty, no single one is sufficient. In practice, developers often use a combination of tools to uncover vulnerabilities. Yet, the basis on which different tools are composed is under explored. In this paper, we examine the composition base by taking advantage of the tool design patterns informed by foraging theory. We follow a design science methodology and carry out a three-step empirical study: mapping 34 foraging-theoretic patterns in a specific vulnerability discovery tool, formulating hypotheses about the value and cost of foraging when considering two composition scenarios, and performing a human-subject study to test the hypotheses. Our work offers insights into guiding developers' tool usage in detecting software vulnerabilities.

Mobile banking apps, belonging to the most security-critical app category, render massive and dynamic transactions susceptible to security risks. Given huge potential financial loss caused by vulnerabilities, existing research lacks a comprehensive empirical study on the security risks of global banking apps to provide useful insights and improve the security of banking apps. Since data-related weaknesses in banking apps are critical and may directly cause serious financial loss, this paper first revisits the state-of-the-art available tools and finds that they have limited capability in identifying data-related security weaknesses of banking apps. To complement the capability of existing tools in data-related weakness detection, we propose a three-phase automated security risk assessment system, named Ausera, which leverages static program analysis techniques and sensitive keyword identification. By leveraging Ausera, we collect 2,157 weaknesses in 693 real-world banking apps across 83 countries, which we use as a basis to conduct a comprehensive empirical study from different aspects, such as global distribution and weakness evolution during version updates. We find that apps owned by subsidiary banks are always less secure than or equivalent to those owned by parent banks. In addition, we also track the patching of weaknesses and receive much positive feedback from banking entities so as to improve the security of banking apps in practice. We further find that weaknesses derived from outdated versions of banking apps or third-party libraries are highly prone to being exploited by attackers. To date, we highlight that 21 banks have confirmed the weaknesses we reported (including 126 weaknesses in total). We also exchange insights with 7 banks, such as HSBC in UK and OCBC in Singapore, via in-person or online meetings to help them improve their apps. We hope that the insights developed in this paper will inform the communities about the gaps among multiple stakeholders, including banks, academic researchers, and third-party security companies.

Ethereum, one of the most popular blockchain platforms, provides financial transactions like payments and auctions through smart contracts. Due to the immense interest in smart contracts in academia, the research community of smart contract security has made a significant improvement recently. Researchers have reported various security vulnerabilities in smart contracts, and developed static analysis tools and verification frameworks to detect them. However, it is unclear whether such great efforts from academia has indeed enhanced the security of smart contracts in reality. To understand the security level of smart contracts in the wild, we empirically studied 55,046 real-world Ethereum smart contracts written in Solidity, the most popular programming language used by Ethereum smart contract developers. We first examined how many well-known vulnerabilities the Solidity compiler has patched, and how frequently the Solidity team publishes compiler releases. Unfortunately, we observed that many known vulnerabilities are not yet patched, and some patches are not even sufficient to avoid their target vulnerabilities. Subsequently, we investigated whether smart contract developers use the most recent compiler with vulnerabilities patched. We reported that developers of more than 98% of real-world Solidity contracts still use older compilers without vulnerability patches, and more than 25% of the contracts are potentially vulnerable due to the missing security patches. To understand actual impacts of the missing patches, we manually investigated potentially vulnerable contracts that are detected by our static analyzer and identified common mistakes by Solidity developers, which may cause serious security issues such as financial loss. We detected hundreds of vulnerable contracts and about one fourth of the vulnerable contracts are used by thousands of people. We recommend the Solidity team to make patches that resolve known vulnerabilities correctly, and developers to use the latest Solidity compiler to avoid missing security patches.

Today, large and complex software is developed with integrated components using application programming interfaces (APIs). Correct usage of APIs in practice presents a challenge due to implicit constraints, such as call conditions or call orders. API misuse, i.e., violation of these constraints, is a well-known source of bugs, some of which can cause serious security vulnerabilities. Although researchers have developed many API-misuse detectors over the last two decades, recent studies show that API misuses are still prevalent. In this paper, we provide a comprehensive empirical study on API-misuse bugs in open-source C programs. To understand the nature of API misuses in practice, we analyze 830 API-misuse bugs from six popular programs across different domains. For all the studied bugs, we summarize their root causes, fix patterns and usage statistics. Furthermore, to understand the capabilities and limitations of state-of-the-art static analysis detectors for API-misuse detection, we develop APIMU4C, a dataset of API-misuse bugs in C code based on our empirical study results, and evaluate three widely-used detectors on it qualitatively and quantitatively. We share all the findings and present possible directions towards more powerful API-misuse detectors.

The occurrence of security vulnerabilities in kernel, especially for macOS/iOS kernel XNU, has increased rapidly in recent years. Naturally, concerns were raised due to the high risks they would lead to, which in general are much more serious than common application vulnerabilities. However, discovering XNU kernel vulnerabilities is always very challenging, and the main approach in practice is still manual analysis, which obviously is not a scalable method. In this paper, we perform an in-depth empirical study on the 406 published XNU kernel vulnerabilities to identify distinguishing characteristics of them and then leverage the features to guide our vulnerability detection, i.e., locating suspicious functions. To further improve the efficiency of vulnerability detection, we present KInspector, a new and lightweight framework to detect XNU kernel vulnerabilities by leveraging feedback-based fuzzing techniques. We thoroughly evaluate our approach on XNU with various versions, and the results turn out to be quite promising: 21 N/0-day vulnerabilities have been discovered in our experiments.

Distributed Denial of Services (DDoS) attacks continue to be one of the most challenging threats to the Internet. The intensity and frequency of these attacks are increasing at an alarming rate. Numerous schemes have been proposed to mitigate the impact of DDoS attacks. This paper presents a comprehensive empirical evaluation of Machine Learning (ML)based DDoS detection techniques, to gain better understanding of their performance in different types of environments. To this end, a framework is developed, focusing on different attack scenarios, to investigate the performance of a class of ML-based techniques. The evaluation uses different performance metrics, including the impact of the “Class Imbalance Problem” on ML-based DDoS detection. The results of the comparative analysis show that no one technique outperforms all others in all test cases. Furthermore, the results underscore the need for a method oriented feature selection model to enhance the capabilities of ML-based detection techniques. Finally, the results show that the class imbalance problem significantly impacts performance, underscoring the need to address this problem in order to enhance ML-based DDoS detection capabilities.

Practitioners use infrastructure as code (IaC) scripts to provision servers and development environments. While developing IaC scripts, practitioners may inadvertently introduce security smells. Security smells are recurring coding patterns that are indicative of security weakness and can potentially lead to security breaches. The goal of this paper is to help practitioners avoid insecure coding practices while developing infrastructure as code (IaC) scripts through an empirical study of security smells in IaC scripts. We apply qualitative analysis on 1,726 IaC scripts to identify seven security smells. Next, we implement and validate a static analysis tool called Security Linter for Infrastructure as Code scripts (SLIC) to identify the occurrence of each smell in 15,232 IaC scripts collected from 293 open source repositories. We identify 21,201 occurrences of security smells that include 1,326 occurrences of hard-coded passwords. We submitted bug reports for 1,000 randomly-selected security smell occurrences. We obtain 212 responses to these bug reports, of which 148 occurrences were accepted by the development teams to be fixed. We observe security smells can have a long lifetime, e.g., a hard-coded secret can persist for as long as 98 months, with a median lifetime of 20 months.

Biometric authentication offers promise for mobile security, but its adoption can be controversial, both from a usability and security perspective. We describe a preliminary study, comparing recollections of biometric adoption by computer security experts and non-experts collected in semi-structured interviews. Initial decisions and thought processes around biometric adoption were recalled, as well as changes in those views over time. These findings should serve to better inform security education across differing levels of technical experience. Preliminary findings indicate that both user groups were influenced by similar sources of information; however, expert users differed in having more professional requirements affecting choices (e.g., BYOD). Furthermore, experts often added biometric authentication methods opportunistically during device updates, despite describing higher security concern and caution. Non-experts struggled with the setting up fingerprint biometrics, leading to poor adoption. Further interviews are still being conducted.

The Java platform and its third-party libraries provide useful features to facilitate secure coding. However, misusing them can cost developers time and effort, as well as introduce security vulnerabilities in software. We conducted an empirical study on StackOverflow posts, aiming to understand developers' concerns on Java secure coding, their programming obstacles, and insecure coding practices. We observed a wide adoption of the authentication and authorization features provided by Spring Security - a third-party framework designed to secure enterprise applications. We found that programming challenges are usually related to APIs or libraries, including the complicated cross-language data handling of cryptography APIs, and the complex Java-based or XML-based approaches to configure Spring Security. In addition, we reported multiple security vulnerabilities in the suggested code of accepted answers on the StackOverflow forum. The vulnerabilities included disabling the default protection against Cross-Site Request Forgery (CSRF) attacks, breaking SSL/TLS security through bypassing certificate validation, and using insecure cryptographic hash functions. Our findings reveal the insufficiency of secure coding assistance and documentation, as well as the huge gap between security theory and coding practices.

Two of the main goals of power management in modern multicore processors are reducing the average power dissipation and delivering the maximum performance up to the physical limits of the system, when demanded. To achieve these goals, hardware manufacturers and operating system providers include sophisticated power and performance management systems, which require detailed information about the current processor state. For example, Intel processors offer the possibility to measure the power dissipation of the processor. In this work, we are evaluating whether such power measurements can be used to establish a covert channel between two isolated applications on the same system; the power covert channel. We present a detailed theoretical and experimental evaluation of the power covert channel on two platforms based on Intel processors. Our theoretical analysis is based on detailed modelling and allows us to derive a channel capacity bound for each platform. Moreover, we conduct an extensive experimental study under controlled, yet realistic, conditions. Our study shows, that the platform dependent channel capacities are in the order of 2000 bps and that it is possible to achieve throughputs of up to 1000 bps with a bit error probability of less than 15%, using a simple implementation. This illustrates the potential of leaking sensitive information and breaking a systems security framework using a covert channel based on power measurements.

Software security is an important aspect that needs to be considered during the entire software development life cycle (SDLC). Integrating software security at each phase of SDLC has become an urgent need. To address software security, various approaches, techniques, methods, practices, and models have been proposed and developed. However, recent research shows that many software development methodologies do not explicitly include methods for incorporating software security during the development of software as it evolves from requirements engineering to its final disposal. The primary objective of this research is to study the state-of-the-art of security in the context of SDLC by following systematic mapping study (SMS). In the second phase, we will identify, through systematic literature review (SLR) and empirical study in the industry, the software security contributions, security challenges and their practices for global software development (GSD) vendors. The ultimate aim is to develop a Software Security Assurance Model (SSAM) to assist GSD vendor organisations in measuring their readiness towards the development of secure software.

In this paper, we focus on the definition of estimators to predict method calls in Android apps. Estimation models are based on information from requirements specification documents (e.g., number of actors, number of use cases, and number of classes in the conceptual model). We have used a dataset containing information on 23 Android apps. After performing data-cleaning, we applied linear regression to build estimation models on 21 data points. Results suggest that measures gathered from requirements specification documents can be considered good predictors to estimate the number of internal calls (i.e., methods invoking other methods present in the app) and external calls (i.e., invocations to API) as well as their sum.

Due to limited time and resources, web software engineers need support in identifying vulnerable code. A practical approach to predicting vulnerable code would enable them to prioritize security auditing efforts. In this paper, we propose using a set of hybrid (static+dynamic) code attributes that characterize input validation and input sanitization code patterns and are expected to be significant indicators of web application vulnerabilities. Because static and dynamic program analyses complement each other, both techniques are used to extract the proposed attributes in an accurate and scalable way. Current vulnerability prediction techniques rely on the availability of data labeled with vulnerability information for training. For many real world applications, past vulnerability data is often not available or at least not complete. Hence, to address both situations where labeled past data is fully available or not, we apply both supervised and semi-supervised learning when building vulnerability predictors based on hybrid code attributes. Given that semi-supervised learning is entirely unexplored in this domain, we describe how to use this learning scheme effectively for vulnerability prediction. We performed empirical case studies on seven open source projects where we built and evaluated supervised and semi-supervised models. When cross validated with fully available labeled data, the supervised models achieve an average of 77 percent recall and 5 percent probability of false alarm for predicting SQL injection, cross site scripting, remote code execution and file inclusion vulnerabilities. With a low amount of labeled data, when compared to the supervised model, the semi-supervised model showed an average improvement of 24 percent higher recall and 3 percent lower probability of false alarm, thus suggesting semi-supervised learning may be a preferable solution for many real world applications where vulnerability data is missing.