Link here

A classical paper showing software also has its own naturalness like natural languages, demonstrating the basics of programming prediction and completion.

• Natural languages are repetitive and predictable, which can be processed by statistical approaches(NLP). Programming code is also very regular, and even more so than natural languages.
• Demonstrate, using standard cross-entropy and perplexity measures, that the above model is indeed capturing the high-level statistical regularity that exists in software at the n-gram level (probabilistic chains of tokens).
• Regularities are specific to both projects and to application domains.

Link here

The paper presents a multi-target fuzzing method, which fuzzes different targets at the same time.

Titan is proposed to perform this work, enabling the fuzzers to distinguish correlations between various targets in the program. And under these correlations, optimizes the input generation efficiently and simultaneously fuzzing different targets.

repo

Introduction:

In practice, more than 1000 potential targets may need verification, which will be costly. Current direct fuzzing only aims at on target at a time, lowering the verification efficiency, and generating multiple instances for fuzzing multiple targets will also be 3.6x slower compared with sequentially applying only one instance at a time for one target.

Link here

The paper presents a Genetic Algorithm(GA) in which whole test suites are evolved with the aim of covering all coverage goals at the same time.

• Whole test suite generation achieves higher coverage than single branch test case generation.
• Whole test suite generation produces smaller test suites than single branch test case generation.

http://www.evosuite.org

Background:

• Current work only target at one coverage goal at a time.
• Engineers should manually write assertion for every test case, so the length of the test case should be as short as possible(after satisfying the coverage prerequisite).

Link here

The paper presents a technique to improve random test generation by incorporating feedback obtained from executing test inputs as they are created.

This paper aims to exposing the potential faults in objects(e.g., Java class), i.e., object oriented, by generating a sequence of method calls to explore bugs.

Background

Random testing is of low efficiency, and may generate useless and redundant test sequences. So RANDOOP is proposed to handle this problem.

Implementation

• Randomly select some method sequences that have been checked with no error.

Link here

This paper proposes a new fuzzing mechanism which integrates several fuzzers to perform a unique fuzzing process. For every workload, one or several optimal mixture of fuzzers are employed for fuzzing. Unlike the early work, autofz:

1. Do not need presetting and human efforts.
2. Allocate fuzzers for every workload, rather than every program.

Background:

• A large amount of fuzzers have been created, which makes it difficult to choose a proper fuzzer for a specific fuzzing.
• No universal fuzzer perpetually outperforms others, so choosing a optimal fuzzer will be difficult.
• The efficiency of a fuzzer may not last for the whole fuzzing process.
• Fuzzing is a random process, a optimal fuzzer may not always be that case.

Link here

This paper doesn’t propose anything new, but creates a system called FirmSec that can detect the TPCs(third-part components) at version-level in firmware, and then recognizes the corresponding vulnerabilities. FirmSec takes IoT firmware images as input and output the vulnerabilities of TPCs contained in the firmware image.

Also, their work creates a database consisting of 34, 136 firmware images. FirmSecDataset

Implementation:

• Preprocess the database, gathering various firmware images both public and private.

• Preprocess the database, gathering various TPCs and their vulnerabilities.

• Take in the firmware image, identify its characters and determines the TPCs(at version level) contained in the firmware.

• Generate the vulnerability report of the firmware.

Link here

This paper performs the first in-depth investigation on the user-data disposal of used IoT devices, and finds that:

1. Most users lack the awareness of disposing used IoT devices.
2. IoT devices collect more sensitive data than users expect, and current data protections of used IoT devices are inadequate.
3. The disposal methods of used IoT devices are often ineffective.

Implementation:

RQ1: Which kinds of sensitive data reside in used IoT devices?

RQ2: Which methods can be used to dispose of sensitive data?

RQ3: Are existing disposal methods effective in erasing the sensitive data?

Link here

This paper proposed a new approach for $REST^{1}$ API fuzzing, which:

1. Focuses more on the long sequence query.
2. Induces a customized attention model to support fuzzing process.
3. Implements a new data-driven security rule checker to capture the new kind of errors caused by undefined parameters.

[1]: REST standard, usually including GET, POST, PUT, DELETE.

Motivation:

Cloud service testing is important, but early works(like RESTler) fail to generate long request sequence for testing, which is not enough to detect deep errors hidden in hard-to-reach states of cloud services. MINER applies length oriented mechanisms to generate long request sequence, and applies a attention model to help pass the semantic checking. Further more, it applies a data-driven security rule checker to capture the new kind of errors caused by undefined parameters.

Link here

This paper aims to detect the logic bugs in the DBMSs. In this paper, logic bugs are defined as bugs that cause a query to return an incorrect result without crashing the DBMS. It randomly selects a row from the table(called pivot row) and syntheses a query whose result should contain the selected row, and then sends the query to the DBMS. By checking if the pivot row is contained in the result, we will know if there is a logic bug.

Motivation:

Logic bugs in DBMSs are hard to find. While former logic bugs detector RAGS applying differential testing to itself, there are still a lot of problems because of $DBMSs'$ $dialects^{1}$ and the $common$ $bugs^{2}$. So SQLancer is proposed to tackle this problem.

Link here

This paper proposes a new recipe to detect the DBMSs crash.

It’s difficult to ensure the syntactic and semantic correctness when fuzzing the DBMSs, and former methods(mutation-based fuzzers, generation-based fuzzers) are not eligible for it. Mutation-based fuzzers are not able to ensure the syntactic and semantic correctness, and generation-based fuzzers can guarantee the syntax correctness of the inputs, but it does utilize any feedback.

Implementation:

• Change the SQL query into IR(a representation methods proposed in the paper), using AST(Abstract Syntax Tree).