All posts for the month February, 2012

This vulnerability I had discovered over Christmas while analysing a JP2 image file. In IrfanView the JP2 image is parsed by its plugin library jpeg2000.dll. The vulnerability lies when processing the Quantization Default (QCD) marker segment causing a stack-based buffer overflow. Initially after discovering the vulnerability and getting control of the EIP register I thought exploiting this would be a piece of cake but only if it was that easy. It might be still very simple for an experienced exploit writer but for me it was a bit of a challenge. Below were the steps I took to exploit this vulnerability and to make it as reliable as possible. A Jpeg2000 image file has a number of marker tags defining what each data block does one being the QCD. The QCD marker segment consists of a number of bytes

Here 0xff5c is the magic value, 0x0023 or 35 bytes is the size and in this case consists of 2 bytes, 1 guard byte and ending with 32 bytes of data. This size can vary though as you might encounter QCD data of only 4 bytes. If we were to increase this QCD data then this would produce our stack-based buffer overflow. So viewing the QCD data part now here are the offsets for this vulnerability

When overflowed we control EIP but at ESP we have only 6 buffer bytes which we can use and the rest can be seen at ESI – 0x3677 (If their is a way to jump to ESI – 0x3677 do let me know). Since I couldn’t work out how to jump to our ESI – 0x3677 or if its even possible I decided to use the only 6 bytes at ESP to see what can I do. So my plan was to use the pwned return address to jump to ESP and then use the 6 bytes to change our ESI value and jump to ESI. After giving some thought I came up with these instructions

66BE8942 mov si,0x4289
FFE6 jmp esi

In this example with these 6 bytes would change the SI value with 0x4289 and then jump to ESI. So what would be the best value to use as this going to be a static value and static values tend to make exploits very unreliable. Spending a bit time testing this on a number of Windows XP SP3 machines I calculated the best value to use would be 0x4289. From the table below the ESI addresses had been taken at the moment of exception when opening the JP2 file various ways

OS

ESI

Buffer2 start (0x65)

JP2 open method

WinXPSP3

0x003472d0

0x00343c59

drop on i_view32.exe

0x003472d0

0x00343c59

drop in IrfanView window

0x003472d0

0x00343c59

double-click

0x0034be00

0x00349791

file–open

WinXPSP3

0x00347818

0x003441a1

drop on i_view32.exe

0x00347818

0x003441a1

drop in IrfanView window

0x00347818

0x003441a1

double-click

0x00347880

0x00348179

file–open

WinXPSP3

0x00037878

0x00034201

drop on i_view32.exe

0x00037900

0x00034289

drop in IrfanView window

0x00347860

0x003441e9

double-click

0x00037658

0x00037f51

file–open

WinXPSP3(VMware)

0x00347560

0x00343ee9

drop on i_view32.exe

0x00347560

0x00343ee9

drop in IrfanView window

0x00347560

0x00343ee9

double-click

0x0034af98

0x00343ee9

file–open

WinXPSP3(MSvpc)

0x00347528

0x00343eb1

drop on i_view32.exe

0x00347528

0x00343eb1

drop in IrfanView window

0x00347528

0x00343eb1

double-click

0x003471b0

0x00347ee1

file–open

As we can see the difference 0x3677 or 13943 bytes for all of them apart from the file–open method. Ignoring the file-open method for now I could have used an instruction to substract with ESI but that would have used up all my 6 bytes leaving no bytes to use for the jump. So I used the mov si,0x???? instruction which changes the last two bytes of our ESI register and using only 4 bytes. To exploit all the 3 remaining methods I used the highest value so that it still falls in our buffer which from the table is 0x4289. The reason the file–open method wont work when using the value 0x4289 is too low and does not fall in our buffer whereas the rest are at the same place or in close proximity.

Here is part of the perl code of our QCD bug and the offsets. If in total is more than 7755 (196 + 4 + 6 + 7549 = 7755) then our EIP changes so thats our buffer limit and I’ll use the entire buffer in my exploit as you’ll see further on

Now that I know the best value to use to change our ESI register using up 4 bytes and leaving 2 bytes for my jump. So a simple jump say call esi (0xffd6) should do the trick, but as always its never straight forward. From the choices of instructions below only JMP DWORD PTR DS:[ESI+??] worked for all JP2 open methods. The JMP DWORD PTR DS:[ESI] instruction did work on one machine though but what good is that working on one XP machine out of 5 :-). The problem with JMP DWORD PTR DS:[ESI+??] instruction is that its uses a 7th byte on our stack which we dont control, luckily this value has always been 0x34 so JMP DWORD PTR DS:[ESI+34] still takes us into our buffer.

Using JMP DWORD PTR DS:[ESI+??] has another problem though in that I had to be precise for it to pick up our next jump address at that point. So once aligned and the buffer filled with call esi addresses (as the location might vary) the call esi took us back into the buffer again and this time our return addresses acted as nops and slided straight to our shellcode.

In the above exploit the JP2 header information was obtained using the ExifProbe tool on a Ubuntu machine.

Applications using Jasper software to parse JP2 files can also be exploited to cause heap-based buffer overflows when copying the QCD marker segment. Have a look at Secunia’s advisory here. I have already made discoveries in applications XnView, IvanView and PhotoLine and they are probably many more to be discovered. If you do discover any vulnerabilities you might want to think about submitting through Secunia’s Vulnerability Coordination Reward Program (SVCRP).

Here is a perl code you can use to create JP2 files with different QCD data sizes to test applications supporting jp2 to see if it triggers any overflows. You just need to change the datalen variable.

This IrfanView exploit only works on Windows XP machines and has not been tested on any Windows 7 machines, also the exploit will not work if the DEP settings have been changed to “OptOut” or “AlwaysOn”, so there are still limitations but someone with more expertise may be able to utilize those 6 bytes at esp more efficiently. Finally an update has been released so make sure to let everyone know those using Irfanview to update their software immediately.