Fujitsu Corporation

Praveen Murthy

Sreeranga P Rajan

Quoc-Sang Phan

Bogdan Copos

Mukul Ranjan Prasad

Indradeep Ghosh

Ryosuke Oishi

Koichiro Takayama

Guodong Li

Oksana Tkachuk

Rafael Kazumiti Morizawa

Erick Bauman

Cong Liu

Fangqi Sun

Thuan Pham

According to an aspect of an embodiment, a method may include obtaining a computer-readable program and analyzing the computer-readable program to identify a constant in code of the computer-readable program. The method may also include obtaining context data associated with the constant from a portion of the code that includes an occurrence of the constant. The method may also include determining a location in the computer-readable program of the occurrence of the constant and analyzing the context data to identify a property of potential inputs to the computer-readable program at the location. The method may also include generating an input for the computer-readable program based on the constant and the identified property and providing the generated input to the computer-readable program during execution of the computer-readable program when execution of the computer-readable program reaches the location.

Generating inputs for computer-program testing

According to an aspect of an embodiment, a method may include guiding automated testing of a binary program with respect to a potentially vulnerable location. The method may include obtaining a first basic block of a first binary program and comparing the first basic block with a second basic block of a second binary program. The comparison may be in response to the second basic block having been previously identified as having a vulnerability. The method may further include identifying the first basic block as a potentially vulnerable location based on a correspondence between the first basic block and the second basic block. The correspondence may be indicated by the comparison of the first basic block with the second basic block. The method may further include guiding a testing execution of the first binary program based on the identification of the first basic block as the potentially vulnerable location.

Guiding automated testing of binary programs

According to an aspect of an embodiment, a method of identifying inputs for automated computer-program testing operations may include obtaining a first input for a computer-readable program that is used during execution of the computer-readable program to cause the computer-readable program to take a first path during execution of the computer-readable program. The method may also include obtaining a second input for the computer-readable program that is used during execution of the computer-readable program to cause the computer-readable program to take a second path during execution of the computer-readable program. The method may also include identifying a sequence of values that is common to both the first input and the second input. The method may also include generating a third input that includes the sequence of values and a new value, the third input configured to be used during execution of the computer-readable program.

Identifying inputs for automated computer-program testing operations

According to some examples, computer-implemented methods for branch coverage guided symbolic execution for hybrid fuzzing are described. An example computer-implemented method may include receiving a seed input of a binary program under analysis (BPUA) that is discovered during testing by a greybox fuzzer. The method may also include concretely executing the seed input in the BPUA, and collecting a trace resulting from the concrete execution of the seed input. The method may further include determining whether the concrete execution of the seed input discovers a new branch. The method may include, responsive to a determination that the concrete execution of the seed input discovers a new branch, updating a bitmap to indicate that the new branch is discovered, wherein the bitmap is utilized by the greybox fuzzer to maintain a record of discovered branches in BPUA, and providing the seed input to the greybox fuzzer.

Branch coverage guided symbolic execution for hybrid fuzz testing of software binaries

A method of detecting concurrency vulnerabilities is provided. A method may include instrumenting read and write access for a program to a shared memory. The method may also include identifying, via a greybox fuzzer, a test case for the program. Further, the method may include analyzing, via the greybox fuzzer and based on the test case, two or more branches of the program that include sets of racing pairs to determine if the test case is a priority test case. In response to the test case being a priority test case, the method may include providing the test case from the greybox fuzzer to a concurrency verification module. The method may also include testing, via the concurrency verification module, the test case with one or more scheduling policies to identify one or more concurrency vulnerabilities.

Concurrency vulnerability detection

A method may include operating a program using an input that causes buffer overflow and determining minimum input length that causes buffer overflow and maximum input length that does not cause buffer overflow. The method may include operating program using first input that includes the maximum input length and second input that includes the minimum input length. The method may include collecting call/return pairs for each function of the program using the first and second input and determining, based on a difference between call/return pairs, a function that causes buffer overflow. The method may include determining whether a number of calls exceeds a threshold. In response to the number of calls exceeding the threshold, the method may include inserting a patch configured to prevent buffer overflow in a calling function.

Reducing buffer overflow

A method of branch exploration in fuzz testing of software binaries includes receiving a set of inputs of a binary program under analysis (BPUA) discovered during testing by a grey box fuzzer. The method includes re-executing the set of inputs. The method includes re-executing a concrete execution of the set of inputs in the BPUA and formation of a constraints tree in which path constraints along paths of the BPUA and conditions at branch points are recorded and marked as explored or unexplored. The method includes selecting a particular number of the unexplored branches of the BPUA. The method includes solving the particular number of unexplored branches with a constraint solver to generate a new set of the particular number of inputs. The method includes communicating the new set of the particular number of inputs to the grey box fuzzer for exploration of different branches of the BPUA.

Unexplored branch search in hybrid fuzz testing of software binaries

A method to determine a valid input sequence for an unknown binary program is provided. The method may include obtaining an input sequence for an unknown binary program. The method may also include obtaining a memory address range for each of one or more variables in the unknown binary program and executing an instrumented version of the unknown binary program with the input sequence as an input to the instrumented version of the unknown binary program. The method may also include recording one or more memory addresses accessed during the execution of the instrumented version of the unknown binary program and determining that the unknown binary program accepts the input sequence as valid based on one or more of the one or more recorded memory addresses corresponding to the memory address range of one or more of the variables in the unknown binary program.

Determination of valid input sequences for an unknown binary program

A method includes selecting a set of printable characters as one or more test inputs for a binary module having no known valid input. The method also includes executing the binary module with the set of printable characters as the one or more test inputs for the binary module. The method also includes determining a number of instructions executed by the binary module responsive to being executed with the set of printable characters. The method also includes generating set data including the one or more printable characters associated with the number of instructions executed for each of the one or more printable characters. The method also includes analyzing the set data to identify one or more printable characters as one or more valid inputs for the binary module based on a comparison of the number of instructions associated with the one or more printable characters and a threshold range.

Determining a valid input for an unknown binary module

A method of vulnerability analysis of a deployed program (program) includes inputting a binary program under analysis (BPUA) derived from the program. The method includes analyzing input/output (I/O) behavior of the program. The method includes discovering inputs to the program based on application of exploration techniques to the BPUA and analysis of the I/O behavior. The method includes determining which of the inputs are negative inputs. The negative inputs are inputs that trigger a response that includes a vulnerability of the program. Based on the negative inputs and triggered responses, the method includes developing a patch for the program that modifies the program to process at least some of the negative inputs without triggering a response that includes the vulnerability. The method includes automatically dispatching the patch.

Autonomous reasoning system for vulnerability analysis

A method to determine valid input sequences for an unknown binary program is provided. The method includes obtaining multiple input sequences, which each include two or more different inputs, for an unknown binary program. The inputs for the input sequences may be valid inputs for the unknown binary program. The method may further include executing an instrumented version of the unknown binary program separately for each input sequence. For each execution of the instrumented version of the unknown binary program, a set of execution traces may be generated by recording execution traces generated by the execution of the instrumented version of the unknown binary program. The method may further include comparing the sets of execution traces and determining which of the input sequences the unknown binary program accepts as valid based on the comparison of the sets of execution traces.

Determining valid inputs for an unknown binary program

A method of determining an attack surface of software may include generating a platform for testing at least one deployment of software code, identifying protocols that are used by the at least one deployment, mapping the protocols to at least one port in the at least one deployment, and computing a metric comprising parameters for the at least one deployment.

Determining an attack surface of software

A method of determining a metric of software code may include generating a flow graph for software code that includes multiple flow graph nodes, including an entry point node, a termination point node, and a metric node. The method may also include generating a contracted flow graph based on the flow graph that includes multiple contracted flow graph nodes. The method may further include determining a through path count within the contracted flow graph based on the contracted flow graph nodes between a first contracted flow graph node that includes the entry point node and a second contracted flow graph node that includes the termination point node. The method may also include determining a metric entry path count within the contracted flow graph based on the contracted flow graph nodes between the first contracted flow graph node and a third contracted flow graph node that includes the metric node.

Determining software metrics

A method includes, by one or more computing devices, determining JavaScript statements to be evaluated, parsing the JavaScript statements, translating the JavaScript statements into Java bytecodes and JavaScript-specific instructions, executing the Java bytecodes in a Java execution engine, calling a JavaScript run-time engine from the Java execution engine, handling one or more semantic operations associated with the JavaScript-specific instructions through use of the JavaScript run-time engine, and providing return values to the Java execution engine. The statements are configured for execution on a computing device. The set of Java bytecodes and JavaScript-specific instructions is configured to conduct symbolic execution of one or more portions of the JavaScript statements. The symbolic execution is configured to evaluate the JavaScript statements.

Symbolic execution and automatic test case generation for JavaScript programs

A method includes constructing a lambda object-oriented scripting language (&#x3bb;) model for a software program written in JavaScript; converting the &#x3bb;model to a continuation-passing style (CPS) model for the software program; constructing a control flow graph (CFG) for the software program based on the CPS model; and optimizing the CPS model by merging a sequence of two or more 'let' operations. The two or more 'let' operations in the CPS model and are generated based on the &#x3bb;model, so that they are represented by a single node in the CFG.

Growing community of inventors

Fremont, CA, United States of America

Praveen Murthy