exploiting winrar 3.10

last friday(24/1), while looking in bugtraq, i found the enclosed advisorie
(/doc/bugtraq.txt). quickly, my mind started to see the possibilities of a
exploit over this vulnerability. if it worked as i would expect, sending a
email with a attached .rar was almost like a autorun: winrar its popular, and
the vulnerable version is widely used(i was using); and, as its one of the
first vulnerabilities in archivers to pop in last times, users where not
attent to the dangers to double-click these files, to inspect their contents.

i first started by hand-constructing a bugged .rar. altought the format was
very know, this job taked a time: i had to build a setup program to insert
the right crc32 values in the right places.

as was in advisorie, i just had to put 260 chars after the dot, in filename,
to trigger the exploit. at crash time, 256 after the dot, its the place to put
your new EIP, and, in the dword before it, a value that goes inside EBX(who
care, anyway). at crash time, several places in stack contained addresses
for our code. there was pointers to the content after the dot, and other to
the start of filename. perfect.

better yet, several registers where usable to reach these addresses: EBP, EDI
and, of course, ESP. it dont take too much time: in a couple of minutes, i
found a JMP [EDI-8], at 0x0047b936, that looked perfect! but not... winrar
translate high chars(>128), to other ones, and the address was crippled. note
that i could use 0 as highest byte of my address: it was the last char of my
buffer, anyway :)

well, so, i did more search. soon a JMP [EBP+18h], in a valid address,
appeared, as in a dream: 0x0048671a. jusr recompiled, and it work perfect. my
"A", that i used to fill the buffer, where running as a row of INC ECX. so,
now to the shellcode...

api usage, in w32 exploits, always cause troubles. but not for winrar: it
imported almost all apis we need, and some more. with a tool i coded for such
occasions(/ut/list_iat), i dumped the import list. the only api we need,
MessageBoxA(), was there.

soon, the high char problem appeared again. high chars where translated to
something else. but i notice a thing: we had a great variation. thus, by
using 0xde, instead of oxcc(int 3), after translation, i had a breakpoint in
the exact place.

faced with this problem, i did the following table(/doc/opcode.bin):

       00 01 02 03   04 05 06 07   08 09 0A 0B   0C 0D 0E 0F

00000  00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00   ................
00010  00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00   ................
00020  00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00   ................
00030  00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00   ................
00040  00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00   ................
00050  00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00   ................
00060  00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00   ................
00070  00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00 ³ 00 00 00 00   ................
00080  C7 FC E9 E2 ³ E4 E0 E5 E7 ³ EA EB E8 EF ³ EE EC C4 C5   ÇüéâäàåçêëèïîìÄÅ
00090  C9 E6 C6 F4 ³ F6 F2 FB F9 ³ FF D6 DC F8 ³ A3 D8 D7 83   ÉæÆôöòûùÿÖÜø£Ø׃
000A0  E1 ED F3 FA ³ F1 D1 AA BA ³ BF AE AC BD ³ BC A1 AB BB   áíóúñѪº¿®¬½¼¡«»
000B0  A6 A6 A6 A6 ³ A6 C1 C2 C0 ³ A9 A6 A6 2B ³ 2B A2 A5 2B   ¦¦¦¦¦ÁÂÀ©¦¦++¢¥+
000C0  2B 2D 2D 2B ³ 2D 2B E3 C3 ³ 2B 2B 2D 2D ³ A6 2D 2B A4   +--+-+ãÃ++--¦-+¤
000D0  F0 D0 CA CB ³ C8 69 CD CE ³ CF 2B 2B A6 ³ 5F A6 CC AF   ðÐÊËÈiÍÎÏ++¦_¦Ì¯
000E0  D3 DF D4 D2 ³ F5 D5 B5 FE ³ DE DA DB D9 ³ FD DD AF B4   ÓßÔÒõÕµþÞÚÛÙýݯ´
000F0  AD B1 3D BE ³ B6 A7 F7 B8 ³ B0 A8 B7 B9 ³ B3 B2 A6 A0   ­±=¾¶§÷¸°¨·¹³²¦ 

with this table, all the rest of the shellcode coding was very easy. just a
check in .lst file, and substitution of some high chars for others.

after setting the params for the api call, a db 098h,10h, that translated to
a db 0ffh,10h,(call eax) after parsing, was placed, and a jmp $, also encoded,
to hang the process where put at the end, and all was ready for the final
test.

it worked perfect under w98 and nt4 sp6. my guess its that it also will work
without problem in any other win32 OS, being the only variable the version of
winrar: surely, others versions dont have the JMP [EBP+18h] that helped me so
much here.

vecna/29a