648160 - (CVE-2011-2363) Mozilla Firefox SVGPointList.appendItem Remote Code Execution Vulnerability (ZDI-CAN-1144)

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Brandon Sterne (:bsterne)]

Attachment: PoC

ZDI-CAN-1144: Mozilla Firefox SVGPointList.appendItem Remote Code Execution Vulnerability

-- CVSS ----------------------------------------------------------------
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- ABSTRACT ------------------------------------------------------------

TippingPoint has identified a vulnerability affecting the following products:

    Mozilla Firefox

-- VULNERABILITY DETAILS -----------------------------------------------

This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Mozilla Firefox. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the code responsible for parsing SVG polygon objects. The code within nsSVGPointList::AppendElement() does not account for user defined getter methods modifying or destroying the parent object during a repaint. An attacker can abuse this flaw to create a dangling pointer which is referenced during the traversal of the SVG container hierarchy. This can be leveraged to execute arbitrary code within the context of the browser.

Version(s)  tested: 3.6.13
Platform(s) tested: Win XP SP3

From content/svg/content/src/nsSVGPointList.cpp:

NS_IMETHODIMP nsSVGPointList::AppendItem(nsIDOMSVGPoint *newItem,
                                         nsIDOMSVGPoint **_retval) {
  ...

  AppendElement(newItem);
  NS_ADDREF(*_retval);
  return NS_OK;
}

nsSVGPointList::AppendElement(nsIDOMSVGPoint* aElement) {
  ...
  mPoints.AppendElement(aElement);
  ...
}

As one can see potentially rogue implementation of nsIDOMSVGPoint is added to |mPoints| collection without check for being trusted/native. Our 
|mPoints| object's getters will be called at least twice. It is important to not break anything during the append itself (when modification event is dispatched) as that most probably would end up with non-exploitable condition. But after that, during the second method call (repaint event), removal of SVGPointElement and related frames leads to the following situation:

(194.198): Access violation - code c0000005 (!!! second chance !!!)
eax=c1c2c3e0 ebx=03c48300 ecx=053db000 edx=053db334 esi=c1c2c3c4
edi=03ced850
eip=102f1473 esp=0012ebfc ebp=0012ec20 iopl=0         nv up ei pl zr na
pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000            
efl=00000246
xul!nsCachedStyleData::GetStyleSVG:
102f1473 8b00            mov     eax,dword ptr [eax] 
ds:0023:c1c2c3e0=????????
0:000> k
ChildEBP RetAddr
0012e838 101c0196 xul!nsCachedStyleData::GetStyleSVG
0012e840 102fab28 xul!nsStyleContext::GetStyleSVG+0xb
0012e848 10631e1e xul!nsIFrame::GetStyleSVG+0x9
0012e860 10631f5f xul!nsSVGGeometryFrame::SetupCairoFill+0x14
0012e8a0 1082fbc7 xul!nsSVGPathGeometryFrame::Render+0xa9
0012e8ec 10758628 xul!nsSVGPathGeometryFrame::PaintSVG+0x31
0012e9bc 107587d3 xul!nsSVGUtils::PaintFrameWithEffects+0x227
0012e9dc 10758628 xul!nsSVGDisplayContainerFrame::PaintSVG+0x30
0012eaac 107588c2 xul!nsSVGUtils::PaintFrameWithEffects+0x227
0012eb20 10758902 xul!nsSVGOuterSVGFrame::Paint+0xdb
0012eb3c 100d54b3 xul!nsDisplaySVG::Paint+0x24 0012eb4c 100b67ac
xul!nsDisplayList::Paint+0x23
0012eb60 100d54b3 xul!nsDisplayClip::Paint+0x2c
0012eb70 100b67ac xul!nsDisplayList::Paint+0x23
0012eb84 100d54b3 xul!nsDisplayClip::Paint+0x2c
0012eb94 100b67ac xul!nsDisplayList::Paint+0x23
0012eba8 100d5908 xul!nsDisplayClip::Paint+0x2c 0012ee8c 1018a3af
xul!nsLayoutUtils::PaintFrame+0x1b8
0012eea8 1018a2b0 xul!PresShell::Paint+0x4f
0012ef10 1017e647 xul!nsViewManager::RenderViews+0xd0
0012ef7c 100de47e xul!nsViewManager::Refresh+0x1a7
0012efd8 100cb1da xul!nsViewManager::DispatchEvent+0x29e
0012f004 101915a5 xul!HandleEvent+0x10a
0012f018 101915fb xul!nsWindow::DispatchEvent+0x25 0012f02c 100afa78
xul!nsWindow::DispatchWindowEvent+0x13
0012f220 100bad7a xul!nsWindow::OnPaint+0x4a8 0012f32c 100d00e5
xul!nsWindow::ProcessMessage+0x15a
0012f368 7e368734 xul!nsWindow::WindowProc+0xf5
0012f394 7e368816 USER32!InternalCallWinProc+0x28 0012f3fc 7e378ea0
USER32!UserCallWinProcCheckWow+0x150
0012f450 7e378eec USER32!DispatchClientMessage+0xa3
0012f478 7c90e473 USER32!__fnDWORD+0x24
0012f49c 7e3694d2 ntdll!KiUserCallbackDispatcher+0x13
0012f4e4 7e3696c7 USER32!NtUserDispatchMessage+0xc
0012f4f4 746ef75e USER32!DispatchMessageA+0xf 0012f52c 746f0078
MSCTF!CModalLoop::WaitRemoveMessage+0x6f
0012f54c 746f0138 MSCTF!CModalLoop::WaitHandleWndMessages+0x127
0012f588 746f067d MSCTF!CModalLoop::BlockFn+0xb4 0012f80c 746f0b92
MSCTF!CProxy::SendReceive+0x1b1
0012f820 746f0ffa MSCTF!CMarshalParamCreator::SendReceive+0x15
0012f88c 746f1738 MSCTF!CProxy::proxy_Param+0x455
0012f8b8 746ed307 MSCTF!CProxyITfLangBarItemSink::OnUpdate+0x3c
0012f8d0 746f0308 MSCTF!CLangBarItemMgr::OnUpdateHandler+0x36
0012f9f4 7e368734 MSCTF!CicMarshalWndProc+0xea
0012fa20 7e368816 USER32!InternalCallWinProc+0x28
0012fa88 7e3689cd USER32!UserCallWinProcCheckWow+0x150
0012fae8 7e368a10 USER32!DispatchMessageWorker+0x306
0012faf8 100d23ae USER32!DispatchMessageW+0xf
0012fb60 0035eeea xul!nsAppShell::ProcessNextNativeEvent+0xae
0012fb84 100f4115 nspr4!PR_IntervalNow+0x1a
0012fbc0 1015fa66 xul!nsThread::ProcessNextEvent+0x155
0012fc00 1022a073 xul!mozilla::ipc::MessagePump::Run+0x196
0012fc3c 1022a03b xul!MessageLoop::RunHandler+0x26
0012fc74 10229140 xul!MessageLoop::Run+0x1f
0012fc80 1022a1eb xul!nsBaseAppShell::Run+0x34 0012fc8c 1002e9fd
xul!nsAppStartup::Run+0x1e
0012ff34 0040133b xul!XRE_main+0xdc3
0012ff80 004016c2 firefox!wmain+0x33b
0012ffc0 7c817077 firefox!__tmainCRTStartup+0x152
0012fff0 00000000 kernel32!BaseProcessStart+0x23

-- CREDIT --------------------------------------------------------------

This vulnerability was discovered by:
    * regenrecht

Comment 1

[Jonathan Watt [:jwatt]]

This should be fixed by the patch in bug 648094.

Comment 2

[Jonathan Watt [:jwatt]]

So I don't seem to be able to use Try server any more to check 1.9.2 changes:

http://tbpl.mozilla.org/?tree=MozillaTry&rev=bb531149bdb1

I guess the build system changes since then make it unusable. Any ideas on how best to proceed?

Comment 3

[Johnny Stenback (:jst)]

Johnathan, can you test this locally? Try is not an option for 1.9.2 and older branches :(

Comment 4

[Jonathan Watt [:jwatt]]

This should be fixed on 1.9.1 and 1.9.2 by the pushed listed in bug 648094 comment 8.

Comment 5

[Al Billings [:abillings - ex-MoCo]]

Verified fixed in build 1 of 1.9.2.18 ( Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110613 Firefox/3.6.18) using PoC, which no longer crashes.