MOAUB #14 – Novell iPrint Client Browser Plugin ExecuteRequest debug Parameter stack overflow

The ExecuteRequest function of this activeX control send operations and parameters to the server without the need of page refresh. Here is how the function is called:
ExecuteRequest(Operation parameter, [ ParameterType=value])

The above function send the operation parameter as first argument and the second argument is for parameters to the operation. For complete list of operations and parameter types refer to iPrint administration guide.

All the operation types need some special parameters except “op-client-version-inf” and “op-client-interface-version” so we use one of them for our tests because we only are care about debug parameter.

As you see in the following code the ExecuteRequest function is implemented at address sub_10008770 as other functions like ShowMessageBox is implemented at sub_1000C300.

The function process our string parameters and in case of validation perform the intended task for each special parameter. In part of that the debug parameter is checked and if exists then the function check for value of ‘true’ or ‘yes’. And the result is program will be in some kind of debug mode operation. Here is the way these parameters are checked:

At address 10008870 the parameter string is checked against ‘debug’ and the function returns -1 if not debug string. And in case of -1 the controls is transferred to loc_10008940 with a conditional jump. But if the parameter-type is debug it checks for true and yes after the ‘=’ character in edx register by calling __mbsicmp function once for ‘true’ then for ‘yes’.

The logic of the program act in a way that after these checks enters to a vulnerable loop that copies our string (for example ‘debug=true’) to the stack.
Here is the implementation of vulnerable loop:

But in case of large enough buffer instead of ‘true’ or ‘yes’ the problematic logic loop copies our string many times until it fill all of the stack with our arbitrary string. After overwriting the stack the program crashes and it happens when the SEH address is overwritten too. And the program execution flow will be transferred to our overwritten SEH address.
For example:

And about the length of buffer if it is too, the sub_1000F290 function when checking parameter type debug it also responsible for bound checking the entire argument. and if it return -1 we never reach our vulnerable loop target. Our examination showed that length of the second string argument should not exceeds more than 1024 character. ( plus the ‘debug=’ string)

In the later patched version of the software the vulnerable loop is replaced by a simple one. The new loop a counter at edi register is checked at the entry point against 0fffh so the max loop execution is 4096 times and it can copies one character to the stack in each iteration. But in the vulnerable more complex loop because of logic flow it copies our entire string parameters many times until it fill the entire stack.

For the purpose of exploitation of this activeX control it is simple to find the offset f SEH address and transfer the control of program to our desired code, but because of possibility of using javascript and in turn allocating heap it is better to use the more reliable heap spray technic that is used in many of explorers and activeX exploits. The only point is not sending to many character more than 1024 character for the second argument of ExecuteRequest function and using ‘debug= ‘+buffer.

Check out the Novell iPrint Client Browser Plugin ExecuteRequest debug Parameter Stack Overflow Exploit.