Simple Analysis and temporary patch for ie ifram Vulnerabilities

Bkbll (bkbll # cnhonker.net) http://www.cnhonker.com

Note: This is just a temporary note.

1. Origin of Vulnerabilities
On bugtraq, someone released an exploit for IE iframe. The method is very clever and can be basically used for 2 K IE6. The Ox is the ox.
2. vulnerability analysis.
When IE processes the iframe tag, it will call SHDOCVW! CBaseBrowser2: SetFrameName function for unicode copy (wcscpy ):
. Text: 71754F67; public: virtual long _ stdcall CBaseBrowser2: SetFrameName (unsigned short *)
. Text: 71754F67? SetFrameName @ CBaseBrowser2 @ UAGJPAG @ Z proc near; data xref:. text: 717233B8o
. Text: 71754F67;. text: 71739900o
. Text: 71754F67
. Text: 71754F67 arg_0 = dword ptr 4
. Text: 71754F67 arg_4 = dword ptr 8
. Text: 71754F67
. Text: 71754F67 mov eax, [esp + arg_0]
. Text: 71754F6B push [esp + arg_4]; wchar_t *
. Text: 71754F6F add eax, 368 h
. Text: 71754F74 push eax; wchar_t *
. Text: 71754F75 call ds :__ imp _ wcscpy
. Text: 71754F7B pop ecx
. Text: 71754F7C pop ecx
. Text: 71754F7D xor eax, eax
. Text: 71754F7F retn 8
. Text: 71754F7F? SetFrameName @ CBaseBrowser2 @ UAGJPAG @ Z endp

When copying the iframe name, no border check is performed, resulting in overflow.

3. Something that can be covered
There is no in-depth research here, and most of them reference the original article of exp.
This exp covers a structure. What structure is unknown at present? According to the author
7178EC02 8B08 mov ecx, dword ptr [EAX]
// [0x0D0D0D0D] = 0x0D0D0D0D, so ecx = 0x0D0D0D0D.
7178EC04 68 847B7071 PUSH 71707B84
7178EC09 50 PUSH EAX
7178EC0A FF11 call near dword ptr [ECX]
Here, because one of the pointers is overwritten, when the program runs to 7178EC0A, it will jump to ecx. While ecx is a controlled area. (In fact
It is by means of brute force expansion of the memory area, so that 0d0d0d can always point to the memory block of our javascript request.) This can be seen from its exp, so I will not talk about it here.

4. Patch.
At present, microsoft has not released patches, but it has not been poisoned. I still want to simply patch it. The idea is to use msvcrt! Wcsncpy to replace wcscpy.
To ensure that one byte exists, the input/return of the program is not strictly the same.
The following is a simple patch:
Text: 71754F67 sub_71754F67 proc near; data xref:. text: 717233B8o
. Text: 71754F67;. text: 71739900o
. Text: 71754F67
. Text: 71754F67 arg_0 = dword ptr 4
. Text: 71754F67
. Text: 71754F67 mov eax, [esp + arg_0]
. Text: 71754F6B push 20 h
. Text: 71754F6D push esi
. Text: 71754F6E add eax, 368 h
. Text: 71754F73 push eax
. Text: 71754F74 mov eax, 78020.fch
. Text: 71754F79 call eax
. Text: 71754F7B pop ecx
. Text: 71754F7C pop ecx
. Text: 71754F7D pop eax
. Text: 71754F7E nop
. Text: 71754F7F retn 8
. Text: 71754F7F sub_71754F67 endp

In the previous call, push esi is used for arg 2. Therefore, push esi is used directly to save several bytes of commands. 0 is returned later,
Because the call address is an 8-byte address and cannot be resolved within 6 bytes (do you have any good solutions ?) Therefore, we have to sacrifice eax. In fact, it is useless to call the returned eax itself.

[Root @ dumplogin c: WINNTsystem32dllcache] # fc/B shdocvw. dll shdocv1_dll.org
Comparing the files shdocvw. dll and SHDOCVW. DLL. ORG
0005436B: 6A FF
0005436C: 20 74
0005436D: 56 24
0005436E: 05 08
0005436F: 68 05
00054370: 03 68
00054371: 00 03
00054373: 50 00
00054374: B8 50
00054375: FC FF
00054376: 04 15
00054377: 01 6C
00054378: 78 12
00054379: FF 70
0005437A: D0 71
0005437D: 58 33
0005437E: 90 C0

5. Use.
After the patch, use zap to delete shdocvw. dll, copy it, open IE, And Then browse the exploit page to find that the attack is invalid.

6. Depressing:

It is strange that loading the modified shdocvw. dll in explorer is different from loading it in IE,
For details, refer:
Explorer:

0: 015> uf SHDOCVW! CBaseBrowser2: SetFrameName
SHDOCVW! CBaseBrowser2: SetFrameName:
00dd4f67 8b442404 & nbs