Process State and Process Depth
For a solid grasp on the concepts of process state and process depth, let's pick an example most people are all too familiar with: ATM banking. Consider the simple state diagram shown in Figure 2.
In a typical ATM transaction, you walk up to the machine (ever so stealthily ensuring you weren't followed), insert your card, enter a PIN, follow a series of on-screen menus to select the amount of money you wish to withdraw, collect your money, and conclude your transaction. This same concept of state and state transitions applies to software; we'll give a specific example in a minute. Each step of the ATM transaction process can be referred to as a state. We define process state as the specific state a target process is in at any given time. Actions, such as inserting a card or selecting a withdrawal amount, transition you from one state to another. How far along you are in the process is referred to as process depth. So, for example, specifying a withdrawal amount happens at a greater depth than entering a PIN.
As a more security-relevant example consider a secure shell (SSH) server. Prior to connecting to the server it is in the initial state. During the authentication process, the server is in the authentication state. Once the server has successfully authenticated a user it is in the authenticated state.
Process depth is a specific measure of the number of "forward" steps required to reach a specific state. Following our SSH server example, consider the state diagram depicted in Figure 3.
The authenticated state is "deeper" in the process than the authentication state because the authentication state is a required substep of the authenticated state. The notion of process state and process depth is an important concept that can create significant complication in fuzzer design. The following example demonstrates such a complication. To fuzz the e-mail address argument of the MAIL FROM verb in an SMTP server, we have to connect to the server and issue either a HELO or EHLO command. As shown in Figure 4, the underlying SMTP implementation may handle the processing of the MAIL FROM command with the same function regardless of what initiation command was used.
In Figure 4, function one is the only function defined to handle MAIL FROM data. Alternatively, as shown in Figure 5, the SMTP implementation might have two separate routines for handling MAIL FROM data depending on the chosen initiation command.
This is actually a real-world example. On September 7, 2006, a security advisory3 detailing a remotely exploitable stack overflow in the SMTP server bundled with Ipswitch Collaboration Suite was published. The overflow occurs when long strings are supplied between the characters @ and : during the parsing of e-mail addresses. The vulnerable parsing routine is only reachable, however, when the connecting client begins the conversation with EHLO. When building fuzzers, be mindful of potential logic splits like this. To get complete coverage, our fuzzer will have to run through all of its e-mail address mutations twice, once through EHLO and once through HELO. What happens if there is another logic split further down the process depth path? The number of necessary iterations for complete coverage starts to increase exponentially.
