Ruslan Rakhmetov, Security Vision
Traditional methods of testing software and its components, such as unit and integration tests, are excellent at verifying expected behavior. However, developers and those who try to break these programs also pay attention to situations in which a program receives data that it is not algorithmically prepared to process. This is the phenomenon we will discuss in this article.
Imagine a child receiving a TV remote and chaotically pressing all the buttons at once. This may cause the device to freeze or open service menus — something an adult user (a conventional test) would never do. Or consider automotive engineers deliberately crashing a car into obstacles at different angles and speeds to uncover hidden structural weaknesses before it reaches the market. These are crash and stress tests, which, in software-development terminology, are otherwise called fuzz tests. We will explain the concept of fuzzing and the specialists who perform it, examine different ways of detecting faults and types of testing, and discuss how this process is integrated into the CI/CD cycle.
1) The Concept and Methodology of Fuzzing
2) Seeds and Testing Rules
3) Memory Sanitizers and Poisoned Bytes
4) Types of Testing
5) Capabilities, Limitations, and Regulation
The Concept and Methodology of Fuzzing
Fuzzing is a dynamic software-testing method in which a system is fed random, specially generated, or intentionally malformed data. The goal is to trigger a crash, a memory leak, or a violation of the application’s logic. Unlike manual testing, where programmers often limit themselves to a few predictable test cases, fuzzing automates the process of trying millions of combinations.
If the program crashes or behaves incorrectly in response to such data, a software defect (bug) is recorded. It could potentially become an attack vector, for example, for a denial-of-service (DoS) attack or remote code execution, possibly enabling an attacker to penetrate the infrastructure.
A specialized program that manages the entire testing process is called a fuzzer. It generates data, sends it to the target program (Target / PUT—Program Under Test), tracks code coverage, monitors the system state, and adapts subsequent generations of input data based on the feedback it receives. The program works like an automatic lock pick or a hacking robot: a mechanical algorithm rapidly tries millions of combinations of a combination lock, analyzing the mechanism’s clicks until the door opens.
Seeds and Testing Rules
Consider the mechanism of evolution. Mutations do not occur “out of nowhere.” They are always based on existing viable genetic code, which is modified in response to external conditions. In fuzz testing, the DNA of such an organism is called its corpus. A test rarely starts with a completely random set of bytes because that is inefficient. To speed up the process, a corpus (seed pool) is used—a set of initial, valid inputs that the target program should be able to process normally.
For example, when testing a PDF parser, the corpus will be a set of valid documents. The fuzzer uses these files as a starting point and begins mutating them iteratively (corpus progression). If a mutated file opens a new code path during testing, the fuzzer saves it back to the corpus for further experiments.
There is another module, or set of rules, that works together with the fuzzer. Its task is to reliably determine whether a security-policy violation has occurred in the program. It is called a bug oracle and works like a carbon-monoxide detector in a home or industrial facility: the dangerous gas has no color or smell, and a person may not notice it until the consequences become critical. The detector responds to the invisible threat and immediately raises the alarm.
A conventional fuzzer can detect only explicit failures, such as a process crash caused by a segmentation fault or a timeout. However, many critical vulnerabilities, such as buffer overflows or reads from uninitialized memory, can occur “silently” without immediately crashing the application. A bug oracle—most often a sanitizer, which we discuss below—makes these hidden errors fatal, forcing the program to terminate immediately and recording the new code path.
Memory Sanitizers and Poisoned Bytes
For a bug oracle to work effectively, the program’s source code is compiled before testing with special tools called sanitizers. Historically, the most effective of these have been AddressSanitizer (ASan) and UndefinedBehaviorSanitizer (UBSan).
ASan
This dynamic-analysis tool, developed by Google engineers, modifies the program code during compilation by inserting strict checks before every access to memory. The foundation of the sanitizer’s architecture is the concept of shadow memory, in which the virtual address space is divided into two parts: the application’s main memory and shadow memory. ASan maps every 8 bytes of the application’s actual memory to 1 byte of shadow memory. This can be compared to a hotel reservation log. The rooms themselves may look identical, but the front desk keeps a register that precisely indicates which rooms are occupied and which are closed for renovation. The sanitizer similarly keeps track of the application’s memory.
To detect buffer overflows or use-after-free, ASan surrounds each allocated memory region (a hotel room) on the heap, stack, or in global variables with special guard zones called redzones. Special hexadecimal markers are written to the corresponding shadow memory, “poisoning” these zones and turning them into poisoned bytes. This is like dye in a cash-in-transit bag: if a robber tries to open the bag, a capsule bursts and “poisons” the banknotes with indelible dye, making the unauthorized access obvious. Before every read or write, the compiled code consults shadow memory. If the program tries to access a redzone, ASan detects the poisoned byte in shadow memory, intercepts the operation, and immediately stops execution with a detailed report.
UBSan
This tool detects anomalous behavior in code that is not directly related to memory access but may lead to logical vulnerabilities. This includes integer overflows, invalid bit shifts, division by zero, and dereferencing null pointers. UBSan adds extra runtime checks to ensure that mathematical operations remain within safe limits.
Imagine an electrical panel in which UBSan acts as a fuse. In the event of a short circuit or voltage surge (undefined behavior or an anomaly), the fuse immediately breaks the circuit before a fire can start.
Types of Testing
As with vulnerability scanning, fuzz testing is performed using three main methods:
Black-box
A method in which the tester or fuzzer has no access to the source code and completely ignores the system’s internal structure is called black-box testing. Data is sent to the program’s external interfaces (network ports, APIs, and the command-line interface), while the fuzzer simply generates information and observes the application’s response: whether it crashed, produced a timeout error, or returned an incorrect status. The main advantage is the speed of preparation and generation. The drawback is extremely low coverage of deeper parts of the code.
It is like trying to guess what is inside a wrapped New Year’s present, or like a blind tasting: a restaurant critic or sommelier samples a dish or wine blind, judging only the final taste without knowing the recipe or what happened in the kitchen.
White-box
In this approach, the tester has complete knowledge of the architecture, and the fuzzer has access to the source code or binary instructions. Symbolic and concolic execution are used here. The system generates the input data needed to pass the most complex logical barriers, such as cryptographic checksum validation. The main drawback is computational complexity and slow performance.
However, it works reliably, like repairing an engine using factory blueprints. The mechanic does not try to guess the cause of a knock by its sound; instead, they use precise diagrams, disassemble the assembly, and mathematically calculate the tolerances and wear of each part.
Grey-box
This hybrid approach, which dominates the modern cybersecurity industry, combines black-box and white-box techniques. It is not like navigating a maze blindfolded, as with a black box, or following a map from above, as with a white box. It is more like searching for scrap metal with a metal detector: the searcher cannot see what is underground, but the device provides an audible signal (feedback). The closer the target, the louder the signal, guiding the search. This feedback mechanism is called coverage-guided fuzzing.
Capabilities, Limitations, and Regulation
Historically, fuzzing was associated exclusively with memory-unsafe languages such as C/C++, where memory-management errors can lead to compromise. However, logical errors and service crashes exist in every ecosystem, which has led to fuzzers being adapted for modern languages: Go has the fuzz function; Rust has cargo-fuzz, which runs on top of libFuzzer; Python has Google’s Atheris; Java has Jazzer; and so on.
This is how the process is integrated into continuous integration and delivery (CI/CD) pipelines, enabling continuous fuzzing. It works like the automatic spell-checker that helped write this article in a text editor. It does not wait until the article is finished; instead, it continuously underlines typos in red in the background as soon as the author types them.
Despite its proven effectiveness in detecting certain types of vulnerabilities, fuzzing has blind spots. The fundamental limitation of the technology is that its algorithms cannot understand business-logic errors or an application’s semantic context. Therefore, an organization must properly assess its assets in the form of applications under development and their connections with internal and external business processes. In these cases, other tools are used: DAST (Dynamic Application Security Testing) scanners, SAST analyzers, unit testing, and manual penetration testing.
Moreover, secure development is also regulated by the state. A foundational document is GOST R 56939-2016 (and its updated editions, such as the 2024 edition), “Information Protection. Secure Software Development. General Requirements.” It contains a direct requirement to perform fuzz testing as part of the dynamic analysis stage of program code. For developers and operators of significant Critical Information Infrastructure (CII) facilities, this requirement is reinforced by FSTEC of Russia Order No. 239 dated December 25, 2017, and Order No. 117 for state information systems (SIS).
Fuzz-testing tools have come a long way—from primitive scripts that sent random garbage to network ports to highly intelligent, distributed architectures. The introduction of powerful memory sanitizers (ASan and UBSan), hybrid methods (grey-box), and concolic analysis (Sydr) revolutionized vulnerability discovery. This has made fuzzing one of the most effective methodologies for combating zero-day (0-day) threats. To protect against other vulnerabilities and insecure configurations, organizations can use solutions such as vulnerability scanners (VS, Vulnerability Scanner) and configuration-audit tools (SPC, Security Profile Compliance).
.jpg)
