Case Study: Zone Alarm

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 .

After running through the loop detection phase, some interesting results are found that are shown in Figure 5 .

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.