Taint Perimeter Detection for Fuzzing Overhead Reduction
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current code coverage techniques face inefficiencies due to runtime overhead and limitations in expanding code coverage, particularly in fuzz testing, where techniques rely on static input sets and expensive instrumentation, making it difficult to detect new code execution paths and improve fuzzing effectiveness over time.
Innovation Solution
A code coverage-based taint perimeter detection system that uses tainted data flow analysis to identify and monitor previously untested branches, employing software breakpoints only at runtime to detect novel code execution, thereby eliminating general runtime overhead and enhancing fuzzing efficiency by focusing on new code coverage induced by tainted inputs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If code coverage tools use modified execution environment or execution instrumentation to instrument the entire binary code, then code coverage measurement is achieved, but runtime overhead increases
Solution Approach 1:
The patent segments the code coverage measurement process by dividing the binary code into basic blocks and identifying only the tainted branches that need monitoring. Instead of instrumenting the entire binary code, the system selectively instruments only the relevant tainted branch targets, significantly reducing runtime overhead while maintaining measurement capability.
Solution Approach 2:
The patent applies local quality by making different parts of the code undergo different treatment. Untainted code paths are left uninstrumented, while only tainted branch targets receive instrumentation. This selective approach ensures that measurement precision is maintained for critical paths without incurring overhead for the entire codebase.
2Measurement precision
If smart fuzzing uses extensive input structure definition or expensive runtime instrumentation, then code coverage is enhanced, but engineering time and execution time increase significantly
Solution Approach 1:
The patent performs preliminary action by conducting static tainted data flow analysis before fuzzing to identify tainted branches and their targets. This pre-computation creates a perimeter set of branch targets that need monitoring, eliminating the need for extensive runtime instrumentation and input structure definitions during actual fuzzing execution.
Solution Approach 2:
The patent extracts only the essential information needed for fuzzing by identifying and isolating tainted branch targets from the entire codebase. Instead of using extensive input structure definitions or monitoring all code paths, the system extracts and monitors only the specific tainted branches that matter for security testing, reducing both engineering and execution time.
3Ease of operation
If fuzzing uses static input sets, then test execution is simple, but it is difficult to detect new code execution paths and improve fuzzing effectiveness
Solution Approach 1:
The patent implements feedback by using software breakpoints at tainted branch targets to detect when new code paths are executed during fuzzing. When a breakpoint is triggered, the system records the new coverage information and uses it to guide subsequent fuzzing iterations, creating a feedback loop that continuously improves code coverage while maintaining simple test execution.
Solution Approach 2:
The patent introduces dynamics by making the fuzzing process adaptive based on detected code coverage. The system dynamically updates the set of monitored tainted branches as new code paths are discovered, allowing the fuzzing to evolve and improve effectiveness over time while starting from simple static input sets.
Data Source
AI summary
A code coverage-based taint perimeter detection system and method for testing software code by determining code coverage and detecting new coverage of the code. Embodiments of the system and method perform tainted data flow analysis on execution traces of the code to determine tainted branch targets. The tainted branch targets may be filtered to remove any tainted branch targets that have already been covered. New coverage can be determined by monitoring the filtered tainted branch targets, which in some embodiments involves the use of software breakpoints that are automatically placed at the locations in the tainted branch targets at runtime. Embodiments of the system and method use an iterative process to ensure that only tainted branch targets that have not already been covered or tested are examined.