Security Bugs Research Articles

Spectrum-based Security Bug Localization by Analyzing Error Propagation

Spectrum-based Security Bug Localization by Analyzing Error Propagation

Software Risk Assessment for Windows Operating Systems with respect to CVSS

CVSS is recognized as a de facto standard for categorizing and measuring software vulnerabilities in both how easy for exploitation for the given security bug and how much impact on a system having the vulnerability in a sense of the three security factors. Meanwhile, since the early 2000s, quantitative risk assessments of software systems had been able to be examined thanks to the accumulated enough datasets for a scientific investigation. However, there are still a lot of research attempts not to be taken in a quantitative examination of software risk assessments. In this paper, we are quantitatively analyzing CVSS scores in vulnerabilities from the three most recent Windows products, namely, Windows 7, Windows 8.1 and Windows 10. The result shows that AML vulnerability discovery model represents Windows vulnerability discovery trend reasonably. Furthermore, we found explicitly that, most of the time, security bugs are compromised with no authentication required systems. This result is corresponding with the output from the previous research based on Web browsers.

Software Risk Assessment for Windows Operating Systems with respect to CVSS

CVSS is recognized as a de facto standard for categorizing and measuring software vulnerabilities in both how easy for exploitation for the given security bug and how much impact on a system having the vulnerability in a sense of the three security factors. Meanwhile, since the early 2000s, quantitative risk assessments of software systems had been able to be examined thanks to the accumulated enough datasets for a scientific investigation. However, there are still a lot of research attempts not to be taken in a quantitative examination of software risk assessments. In this paper, we are quantitatively analyzing CVSS scores in vulnerabilities from the three most recent Windows products, namely, Windows 7, Windows 8.1 and Windows 10. The result shows that AML vulnerability discovery model represents Windows vulnerability discovery trend reasonably. Furthermore, we found explicitly that, most of the time, security bugs are compromised with no authentication required systems. This result is corresponding with the output from the previous research based on Web browsers.

CVE-assisted large-scale security bug report dataset construction method

Identifying SBRs (security bug reports) is crucial for eliminating security issues during software development. Machine learning are promising ways for SBR prediction. However, the effectiveness of the state-of-the-art machine learning models depend on high-quality datasets, while gathering large-scale datasets are expensive and tedious. To solve this issue, we propose an automated data labeling approach based on iterative voting classification. It starts with a small group of ground-truth traing samples, which can be labeled with the help of authoritative vulnerability records hosted in CVE (Common Vulnerabilities and Exposures). The accuracy of the prediction model is improved with an iterative voting strategy. By using this approach, we label over 80k bug reports from OpenStack and 40k bug reports from Chromium. The correctness of these labels are then manually reviewed by three experienced security testing members. Finally, we construct a large-scale SBR dataset with 191 SBRs and 88,472 NSBRs (non-security bug reports) from OpenStack; and improve the quality of existing SBR dataset Chromium by identifying 64 new SBRs from previously labeled NSBRs and filtering out 173 noise bug reports from this dataset. These share datasets as well as the proposed dataset construction method help to promote research progress in SBR prediction research domain.

T reble

This paper presents our experience with T reble , a two-year initiative to build the modular base in Android, a Java-based mobile platform running on the Linux kernel. Our T reble architecture splits the hardware independent core framework written in Java from the hardware dependent vendor implementations (e.g., user space device drivers, vendor native libraries, and kernel written in C/C++). Cross-layer communications between them are done via versioned, stable inter-process communication interfaces whose backward compatibility is tested by using two API compliance suites. Based on this architecture, we repackage the key Android software components that suffered from crucial post-launch security bugs as separate images. That not only enables separate ownerships but also independent updates of each image by interested ecosystem entities. We discuss our experience of delivering T reble architectural changes to silicon vendors and device makers using a yearly release model. Our experiments and industry rollouts support our hypothesis that giving more freedom to all ecosystem entities and creating an equilibrium are a transformation necessary to further scale the world largest open source ecosystem with over two billion active devices.

How Developers Diagnose Potential Security Vulnerabilities with a Static Analysis Tool

While using security tools to resolve security defects, software developers must apply considerable effort. Success depends on a developer's ability to interact with tools, ask the right questions, and make strategic decisions. To build better security tools and subsequently help developers resolve defects more accurately and efficiently, we studied the defect resolution process—from the questions developers ask to their strategies for answering them. In this paper, we report on an exploratory study with novice and experienced software developers. We equipped them with Find Security Bugs, a security-oriented static analysis tool, and observed their interactions with security vulnerabilities in an open-source system that they had previously contributed to. We found that they asked questions not only about security vulnerabilities, associated attacks, and fixes, but also questions about the software itself, the social ecosystem that built the software, and related resources and tools. We describe the strategic successes and failures we observed and how future tools can leverage our findings to encourage better strategies.

Using memory propagation tree to improve performance of protocol fuzzer when testing ICS

Protocol fuzzers are widely used for finding vulnerabilities and security bugs in the program. The main techniques used by protocol fuzzers can be divided into 2 categories: generation-based and mutation-based fuzzing. The generation-based fuzzing generates data messages using an official specification (i.e., grammar), while the mutation-based fuzzing performs random transformations on a prepared message. But these two types of fuzzing techniques are ineffective or inefficient when testing industrial control system (ICS), because many ICS protocols are unknown, undocumented or proprietary. The generation-based fuzzing cannot work well without specifications, while the mutation-based fuzzing cannot achieve high branch coverage. In this paper, we present Miff (abbreviation of the system using “M”P tree to “i”mprove per“f”ormance of “f”uzzer) that aims at automatically abstracting data models from ICS messages. The data model generated by Miff can be used to direct protocol fuzzers to test ICS. Miff has three processing stages: (1) by instrumenting and monitoring program execution, Miff obtains the execution context information, builds memory propagation (MP) tree for every byte in the message, and identifies protocol field boundaries based on the similarity between MP trees; (2) by using information-theoretic measures, Miff infers the type of every field; (3) according to analysis results of the first two stages, Miff decides the mutation strategy for every field, which combines with the field boundary and type information to form the data model. We have implemented a prototype of Miff and applied it into 4 open-source protocol fuzzers. Our experimental results show that, Miff can enable the generation-based fuzzing to test ICS even if the specification is absent, and improve the performance of the mutation-based fuzzing to achieve higher branch coverage with less test cases.

Text Filtering and Ranking for Security Bug Report Prediction

Security bug reports can describe security critical vulnerabilities in software products. Bug tracking systems may contain thousands of bug reports, where relatively few of them are security related. Therefore finding unlabelled security bugs among them can be challenging. To help security engineers identify these reports quickly and accurately, text-based prediction models have been proposed. These can often mislabel security bug reports due to a number of reasons such as class imbalance, where the ratio of non-security to security bug reports is very high. More critically, we have observed that the presence of security related keywords in both security and non-security bug reports can lead to the mislabelling of security bug reports. This paper proposes FARSEC, a framework for filtering and ranking bug reports for reducing the presence of security related keywords. Before building prediction models, our framework identifies and removes non-security bug reports with security related keywords. We demonstrate that FARSEC improves the performance of text-based prediction models for security bug reports in 90 percent of cases. Specifically, we evaluate it with 45,940 bug reports from Chromium and four Apache projects. With our framework, we mitigate the class imbalance issue and reduce the number of mislabelled security bug reports by 38 percent.

NeuFuzz: Efficient Fuzzing With Deep Neural Network

Coverage-guided graybox fuzzing is one of the most popular and effective techniques for discovering vulnerabilities due to its nature of high speed and scalability. However, the existing techniques generally focus on code coverage but not on vulnerable code. These techniques aim to cover as many paths as possible rather than to explore paths that are more likely to be vulnerable. When selecting the seeds to test, the existing fuzzers usually treat all seed inputs equally, ignoring the fact that paths exercised by different seed inputs are not equally vulnerable. This results in wasting time testing uninteresting paths rather than vulnerable paths, thus reducing the efficiency of vulnerability detection. In this paper, we present a solution, NeuFuzz, using the deep neural network to guide intelligent seed selection during graybox fuzzing to alleviate the aforementioned limitation. In particular, the deep neural network is used to learn the hidden vulnerability pattern from a large number of vulnerable and clean program paths to train a prediction model to classify whether paths are vulnerable. The fuzzer then prioritizes seed inputs that are capable of covering the likely to be vulnerable paths and assigns more mutation energy (i.e., the number of inputs to be generated) to these seeds. We implemented a prototype of NeuFuzz based on an existing fuzzer PTfuzz and evaluated it on two different test suites: LAVA-M and nine real-world applications. The experimental results showed that NeuFuzz can find more vulnerabilities than the existing fuzzers in less time. We have found 28 new security bugs in these applications, 21 of which have been assigned as CVE IDs.

SAIS: Self-Adaptive Identification of Security Bug Reports

Among various bug reports (BRs), security bug reports (SBRs) are unique because they require immediate concealment and fixes. When SBRs are not identified in time, attackers can exploit the vulnerabilities. Prior work identifies SBRs via text mining, which requires a predefined keyword list and trains a classifier with known SBRs and non-security bug reports (NSBRs). The former approach is not reliable, because (1) as the contexts of security vulnerabilities and terminology of SBRs change over time, the predefined list will become out-dated; and (2) users may have insufficient SBRs for training. We introduce a semi-supervised learning-based approach, Sais , to adaptively and reliably identify SBRs. Given a project's BRs containing some labeled SBRs, many more NSBRs, and unlabeled BRs, Sais iteratively mines keywords, trains a classifier based on the keywords from the labeled data, classifies unlabeled BRs, and augments its training data with the newly labeled BRs. Our evaluation shows that Sais is useful for identifying SBRs.

How security bugs are fixed and what can be improved: an empirical study with Mozilla

How security bugs are fixed and what can be improved: an empirical study with Mozilla

Practice on Detecting Malware in Virtualized Environment of Cloud

Virtual machines are expanding in notoriety and are being broadly received. The idea of a virtual machine is however not new. As per the cloud hypervisor is one of the major component of security. This paper consist of survey of various research paper in this domain. First we discussed about the functionality of the hypervisor form the research paper. Next, Paper discussed about various malware which has effect on hypervisor and the functionality or feature of that malware which make them to effect the hypervisor in virtualized environment. At long last, late research in the territory of hypervisor security is dissected. Research into the security of hypervisors is constrained. Most security examine is gathered in the cloud stage where hypervisors plays a noticeable part. As an assessment of security, some security bugs announced for the Hypervisor framework and the comparing relief methodologies utilized are likewise talked about.

Classification of Security Bugs Using emotional word

Classification of Security Bugs Using emotional word

Who guards the guards? formal validation of the Arm v8-m architecture specification

Software and hardware are increasingly being formally verified against specifications, but how can we verify the specifications themselves? This paper explores what it means to formally verify a specification. We solve three challenges: (1) How to create a secondary, higher-level specification that can be effectively reviewed by processor designers who are not experts in formal verification; (2) How to avoid common-mode failures between the specifications; and (3) How to automatically verify the two specifications against each other. One of the most important specifications for software verification is the processor specification since it defines the behaviour of machine code and of hardware protection features used by operating systems. We demonstrate our approach on ARM's v8-M Processor Specification, which is intended to improve the security of Internet of Things devices. Thus, we focus on establishing the security guarantees the architecture is intended to provide. Despite the fact that the ARM v8-M specification had previously been extensively tested, we found twelve bugs (including two security bugs) that have all been fixed by ARM.

Automated testing of graphics shader compilers

We present an automated technique for finding defects in compilers for graphics shading languages. key challenge in compiler testing is the lack of an oracle that classifies an output as correct or incorrect; this is particularly pertinent in graphics shader compilers where the output is a rendered image that is typically under-specified. Our method builds on recent successful techniques for compiler validation based on metamorphic testing, and leverages existing high-value graphics shaders to create sets of transformed shaders that should be semantically equivalent. Rendering mismatches are then indicative of shader compilation bugs. Deviant shaders are automatically minimized to identify, in each case, a minimal change to an original high-value shader that induces a shader compiler bug. We have implemented the approach as a tool, GLFuzz, targeting the OpenGL shading language, GLSL. Our experiments over a set of 17 GPU and driver configurations, spanning the main 7 GPU designers, have led to us finding and reporting more than 60 distinct bugs, covering all tested configurations. As well as defective rendering, these issues identify security-critical vulnerabilities that affect WebGL, including a significant remote information leak security bug where a malicious web page can capture the contents of other browser tabs, and a bug whereby visiting a malicious web page can lead to a ``blue screen of death'' under Windows 10. Our findings show that shader compiler defects are prevalent, and that metamorphic testing provides an effective means for detecting them automatically.

What do developers search for on the web?

Developers commonly make use of a web search engine such as Google to locate online resources to improve their productivity. A better understanding of what developers search for could help us understand their behaviors and the problems that they meet during the software development process. Unfortunately, we have a limited understanding of what developers frequently search for and of the search tasks that they often find challenging. To address this gap, we collected search queries from 60 developers, surveyed 235 software engineers from more than 21 countries across five continents. In particular, we asked our survey participants to rate the frequency and difficulty of 34 search tasks which are grouped along the following seven dimensions: general search, debugging and bug fixing, programming, third party code reuse, tools, database, and testing. We find that searching for explanations for unknown terminologies, explanations for exceptions/error messages (e.g., HTTP 404), reusable code snippets, solutions to common programming bugs, and suitable third-party libraries/services are the most frequent search tasks that developers perform, while searching for solutions to performance bugs, solutions to multi-threading bugs, public datasets to test newly developed algorithms or systems, reusable code snippets, best industrial practices, database optimization solutions, solutions to security bugs, and solutions to software configuration bugs are the most difficult search tasks that developers consider. Our study sheds light as to why practitioners often perform some of these tasks and why they find some of them to be challenging. We also discuss the implications of our findings to future research in several research areas, e.g., code search engines, domain-specific search engines, and automated generation and refinement of search queries.

Do bugs foreshadow vulnerabilities? An in-depth study of the chromium project

As developers face an ever-increasing pressure to engineer secure software, researchers are building an understanding of security-sensitive bugs (i.e. vulnerabilities). Research into mining software repositories has greatly increased our understanding of software quality via empirical study of bugs. Conceptually, however, vulnerabilities differ from bugs: they represent an abuse of functionality as opposed to insufficient functionality commonly associated with traditional, non-security bugs. We performed an in-depth analysis of the Chromium project to empirically examine the relationship between bugs and vulnerabilities. We mined 374,686 bugs and 703 post-release vulnerabilities over five Chromium releases that span six years of development. We used logistic regression analysis, ranking analysis, bug type classifications, developer experience, and vulnerability severity metrics to examine the overarching question: are bugs and vulnerabilities in the same files? While we found statistically significant correlations between pre-release bugs and post-release vulnerabilities, we found the association to be weak. Number of features, source lines of code, and pre-release security bugs are, in general, more closely associated with post-release vulnerabilities than any of our non-security bug categories. In further analysis, we examined sub-types of bugs, such as stability-related bugs, and the associations did not improve. Even the files with the most severe vulnerabilities (by measure of CVSS or bounty payouts) did not show strong correlations with number of bugs. These results indicate that bugs and vulnerabilities are empirically dissimilar groups, motivating the need for security engineering research to target vulnerabilities specifically.

Enhancing Conformance Testing Using Symbolic Execution for Network Protocols

Security protocols are notoriously difficult to get right, and most go through several iterations before their hidden security vulnerabilities, which are hard to detect, are triggered. To help protocol designers and developers efficiently find non-trivial bugs, we introduce SYMCONF, a practical conformance testing tool that generates high-coverage test input packets using a conformance test suite and symbolic execution. Our approach can be viewed as the combination of conformance testing and symbolic execution: 1) it first selects symbolic inputs from an existing conformance test suite; 2) it then symbolically executes a network protocol implementation with the symbolic inputs; and 3) it finally generates high-coverage test input packets using a conformance test suite. We demonstrate the feasibility of this methodology by applying SYMCONF to the generation of a stream of high quality test input packets for multiple implementations of two network protocols, the Kerberos Telnet protocol and Dynamic Host Configuration Protocol (DHCP), and discovering non-trivial security bugs in the protocols.

On the evolution of security bugs

On the evolution of security bugs

Comparative Analysis of Wireless Security Protocols: WEP vs WPA

Data security in wireless network has posed as a threat that has stuck to the core of data communication from point A to point B. There have been a variety of security issues raised in wired and wireless networks and security specialists proposed a variety of solutions. The proposed security solutions in wired networks could not be successfully implemented in wireless networks to identify, authenticate and authorize users due to infrastructural and working principles of wireless networks. Data on wireless network are much exposed to threats because the network is been broadcasted unlike a wired network. Researchers have proposed WEP and WPA to provide security in wireless networks. This research is going to compare the WEP and WPA mechanism for better understanding of their working principles and security bugs.