|Informative Information for the Uninformed|
For a case study the author chose Zone Alarm's vsdatant.sys driver. This driver does a lot of the dirty work for Zone Alarm such as packet filtering, application monitoring, and other kernel level duties. Some may wonder why it would be worthwhile to find loops in a driver. In Zone Alarm's case, the user can hope to find miscalculations in lengths where they didn't convert a signed to unsigned value properly and therefore may cause an overflow when looping. Anytime an application takes data in remotely that may be type-casted at some point, there is always a great chance for loops that overflow their bounds.
When analyzing the Zone Alarm driver the user needs to select certain options to get a better idea of what is going on with loops. First, the user should select verbose output and All Loops Highlighting of Functions to see if there are any dangerous function calls within the loop. This is illustrated in Figure 4 .
Visiting the address 0x00011a21 in IDA shows the loop. To begin, the reader will need to find the loop's entry point, which is at:
.text:00011A1E jz short loc_11A27
At the loop's entry point, the reader will notice:
.text:00011A27 push 206B6444h ; Tag .text:00011A2C push edi ; NumberOfBytes .text:00011A2D push 1 ; PoolType .text:00011A2F call ebp ;ExAllocatePoolWithTag
At this point, the reader can see that every time the loop passes through its entry point it will allocate memory. To determine if the attacker can cause a double free error, further investigation is needed.
.text:00011A31 mov esi, eax .text:00011A33 test esi, esi .text:00011A35 jz short loc_11A8F
If the memory allocation within the loop fails, the loop terminates correctly. The next call in the loop is to ZwQuerySystemInformation which tries to acquire the SystemProcessAndThreadsInformation.
.text:00011A46 mov eax, [esp+14h+var_4] .text:00011A4A add edi, edi .text:00011A4C inc eax .text:00011A4D cmp eax, 0Fh .text:00011A50 mov [esp+14h+var_4], eax .text:00011A54 jl short loc_11A1C
This part of the loop is quite un-interesting. In this segment the code increments a counter in eax until eax is greater than 15. It is obvious that it is not possible to cause a double free error in this case because the user has no control over the loop condition or data within the loop. This ends the investigation into a possible double free error.
Above is a good example of how to analyze loops that may be of interest. With all binary analysis it is important to not only identify dangerous function calls but to also identify if the attacker can control data that might be manipulated or referenced within a loop.