CVE-2014-1773

CClipStack::PushClipRect() Indexation de tableau invalide

Tout d'abord, en commençant par la pile d'appels du crash avec pageheap activé :

ChildEBP RetAddr 0919aac8 6b58459f MSHTML!CWorldTransform::IsAxisAligned 0919ab40 6ba228e9 MSHTML!CDispSurface::CClipStack::PushClipRect+0x1a2 0919aba4 6be25b58 MSHTML!CDispSurface::PushClipRectInternal+0x2f 0919abc0 6bf1118f MSHTML!CDispSurface::PushClipRectUser+0x26 0919ac24 6bf1157e MSHTML!CCanvasCompositor::ClearRightAndBelowRenderedRegion+0xcd 0919acd8 6b28108c MSHTML!CCanvasCompositor::ExecuteCompositionEffects+0x34d 0919ace0 6b2802f4 MSHTML!CCanvasCompositor::Flush+0x3d 0919ace8 6bf0c867 MSHTML!CCanvasCompositor::~CCanvasCompositor+0x10 0919ae28 6bf0b668 MSHTML!CCanvasRenderingContext2D::StrokeRectInternal+0x1b3 0919ae70 6bf0e032 MSHTML!CCanvasRenderingContext2D::ExecuteStrokeRect+0x1c5 0919aebc 6bd74b6f MSHTML!CCanvasRenderingContext2D::Var_strokeRect+0xac 0919aee0 6ae7056e MSHTML!CFastDOM::CCanvasRenderingContext2D::Trampoline_strokeRect+0x3b 0919af50 6ae6cdda jscript9!Js::JavascriptExternalFunction::ExternalFunctionThunk+0x165 0919b328 6ae6dc86 jscript9!Js::InterpreterStackFrame::Process+0x1e74 0919b474 09560fd9 jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x1e7

Si nous reculons d'une fonction, celui-ci définit le pointeur d'objet utilisé par le crash :

.text:63CDE575 ; public: long __thiscall CDispSurface::CClipStack::PushClipRect(class CRectF const &, class CWorldTransform const *, bool, bool) .text:63CDE575 mov edi, edi .text:63CDE577 push ebp .text:63CDE578 mov ebp, esp .text:63CDE57A sub esp, 64h .text:63CDE57D and [ebp+var_8], 0 .text:63CDE581 mov edx, ecx .text:63CDE583 push ebx .text:63CDE584 push esi .text:63CDE585 mov esi, [ebp+arg_0] .text:63CDE588 push edi .text:63CDE589 lea edi, [ebp+var_28] .text:63CDE58C mov [ebp+var_4], edx .text:63CDE58F movsd .text:63CDE590 movsd .text:63CDE591 movsd .text:63CDE592 movsd .text:63CDE593 mov esi, [ebp+arg_4] .text:63CDE596 test esi, esi .text:63CDE598 jnz loc_63B1A8DF .text:63CDE59E .text:63CDE59E loc_63CDE59E: .text:63CDE59E imul ecx, [edx+4], 18h .text:63CDE5A2 xor bl, bl .text:63CDE5A4 mov eax, [edx+8] .text:63CDE5A7 add eax, 0FFFFFFE8h .text:63CDE5AA add eax, ecx .text:63CDE5AC mov [ebp+arg_0], eax .text:63CDE5AF mov edi, [eax+14h]

L'objet externe, CDispSurface, contient un objet CClipStack à l'intérieur. L'objet CClipStack commence à l'offset 0x64 de l'objet CDispSurface. CClipStack est essentiellement une sous-classe de CImplAry, semble-t-il, qui est une classe de tableau générique utilisée partout par Internet Explorer pour les tableaux. Dans la fonction ci-dessus, CDispSurface::CClipStack::PushClipRect, le pointeur 'this' est le sous-objet CClipStack à l'intérieur du CDispSurface externe.

L'objet CClipStack ressemble à ceci :

DWORD dwMaxElems; DWORD dwCurElems; VOID *pElems;

Donc, en regardant le code ci-dessus, vous pouvez deviner ce qui se passe. Ce que fait le code ci-dessus, c'est extraire le dernier élément du tableau CClipStack. Chaque élément du tableau a une taille de 0x18 octets, d'où :

imul ecx, [edx+4], 18h ; dwCurElems * 0x18 mov eax, [edx+8] ;pElems

Mais ensuite vous voyez ce qui suit :

add eax, 0FFFFFFE8h ; soustrait 0x18 de pElems add eax, ecx ; pElems += (dwCurElems * 0x18)

Cependant, si le tableau est vide, dwCurElems * 0x18 '==' 0, et donc pElems pointera en réalité DERRIÈRE le début du tableau, dans le bloc de tas adjacent situé en dessous. Le tableau contient des objets de type CWorldTransform, comme vous pouvez le déduire du code qui plante peu après avoir extrait l'objet du tableau. ecx est le pointeur d'objet pris à partir de l'opération 'mov edi, [eax+14h]' :

.text:63B1A940 ; public: bool __thiscall CWorldTransform::IsAxisAligned(void)const

.text:63B1A940 test dword ptr [ecx+8], 80000000h ;ecx == MAUVAIS

Donc, où le tableau est-il alloué :

MSHTML!CDispSurface::CClipStack::PushClipRect+0x32: 6b97e5a7 83c0e8 add eax,0FFFFFFE8h 0:013> !heap -p -a eax address 0c4b0fa0 found in _DPH_HEAP_ROOT @ 211000 in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize) c45123c: c4b0fa0 60 - c4b0000 2000 739f8e89 verifier!AVrfDebugPageHeapAllocate+0x00000229 77a95e7a ntdll!RtlDebugAllocateHeap+0x00000030 77a5a3ba ntdll!RtlpAllocateHeap+0x000000c4 77a25a70 ntdll!RtlAllocateHeap+0x0000023a 6b55c592 MSHTML!CImplAry::EnsureSizeWorker+0x00000061 6b584513 MSHTML!CDispSurface::BeginDraw+0x00000122 6b2847a0 MSHTML!CCanvasRenderingContext2D::BeginDraw+0x00000041 6b286155 MSHTML!CCanvasContextBase::OpenBitmapRenderTarget+0x00000014 6b283b77 MSHTML!CCanvasCompositor::Initialize+0x0000102f 6b285cf7 MSHTML!CCanvasRenderingContext2D::StrokeGeometry+0x00000131 6b285090 MSHTML!CCanvasRenderingContext2D::ExecuteStroke+0x000002c4 6b284dae MSHTML!CFastDOM::CCanvasRenderingContext2D::Trampoline_stroke+0x00000035 6ae7056e jscript9!Js::JavascriptExternalFunction::ExternalFunctionThunk+0x00000165 6ae6cdda jscript9!Js::InterpreterStackFrame::Process+0x00001e74 6ae6dc86 jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x000001e7

Il se trouve dans le bac LFH de taille 0x60. Nous pouvons contrôler le bloc situé derrière le tableau en effectuant un façonnage du tas. Mais la mauvaise partie du code ci-dessus est que le calcul pour extraire l'objet utilisé est le suivant :

(BYTE *)pArrayStart - 0x18 + 0x14 => (BYTE *)pArrayStart - 0x4

Cela conduit à utiliser le champ de flags/index de l'en-tête du bloc LFH comme pointeur d'objet. Ce n'est pas vraiment bon car les octets de ce champ ne sont pas super contrôlables (je pense).

Pour voir comment contrôler éventuellement ce second dword de l'en-tête LFH :

http://illmatics.com/Understanding_the_LFH.pdf

Collaboration avec Sean Larsson