the string (this is done in 6e9007cf). This distance is stored in [ebp-0x20],
and is essentially the length of the string I’m are currently dealing with.
An interesting comparison is done in 6e900804, where the function com-
pares the string length with 0x190(400 in decimal), and throws a C++ excep-
tion using _CxxThrowExceptionif it’s 400 or above. So, it seems that the
function does have some kind of boundary checking on the URL. Where is the
problem here? I’m just getting to it.
When the string length comparison succeeds, the function jumps to where it
sets up a call to DecodeURLEscapes. DecodeURLEscapestakes four parame-
ters: The pointer to the string from [ebp-0x18], a pointer to the string length
from [ebp-0x20], a pointer to the beginning of the local variable area
from [ebp-0x1dc], and offset +8 in EXTENSION_CONTROL_BLOCK. Clearly
DecodeURLEscapesis about to copy, or decode, a potentially problematic
string into the local variable area in the stack.
DecodeURLEscapes
In order to better understand this bug, let’s take a look at DecodeURLEscapes,
even though it is not strictly where the bug is at. This function is presented in
Listing 7.3. Again, this listing is incomplete and only includes the relevant areas
of DecodeURLEscapes.
query!DecodeURLEscapes:
68cc697e mov eax,0x68d667cc
68cc6983 call query!_EH_prolog (68d4b250)
68cc6988 sub esp,0x30
68cc698b push ebx
68cc698c push esi
68cc698d xor eax,eax
68cc698f push edi
68cc6990 mov edi,[ebp+0x10]
68cc6993 mov [ebp-0x3c],eax
68cc6996 mov [ebp-0x38],eax
68cc6999 mov ecx,[ebp+0xc]
68cc699c mov [ebp-0x4],eax
68cc699f mov [ebp-0x18],eax
68cc69a2 mov ecx,[ecx]
68cc69a4 cmp ecx,eax
68cc69a6 mov [ebp-0x10],ecx
68cc69a9 jz query!DecodeURLEscapes+0x99 (68cc6a17)
68cc69ab mov esi,[ebp+0x8]
68cc69ae mov eax,ecx
68cc69b0 inc eax
68cc69b1 mov [ebp-0x14],eax
68cc69b4 movzx bx,byte ptr [esi]Listing 7.3 Disassembly of DecodeURLEscapes function from query.dll. (continued)
Auditing Program Binaries 267