Bug 648090 (CVE-2011-0083)

Mozilla Firefox SVGPathSegList.replaceItem Remote Code Execution Vulnerability (ZDI-CAN-1142)




7 years ago
6 years ago


(Reporter: bsterne, Assigned: jwatt)



1.9.2 Branch

Firefox Tracking Flags

(firefox5- unaffected, status2.0 unaffected, blocking1.9.2 .18+, status1.9.2 .18-fixed, blocking1.9.1 .20+, status1.9.1 .20-fixed)


(Whiteboard: [sg:critical?])


(1 attachment)



7 years ago
Created attachment 524240 [details]

ZDI-CAN-1142: Mozilla Firefox SVGPathSegList.replaceItem 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 

    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 path segment objects. The function nsSVGPathSegList::ReplaceItem() does
not account for deletion of the segment object list within a user defined DOMAttrModified EventListener. Code within
nsSVGPathSegList::ReplaceItem() references the segment list without verifying that it was not deleted in the aforementioned callback. This
can be abused to create a dangling reference which 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/nsSVGPathSegList.cpp:

NS_IMETHODIMP nsSVGPathSegList::ReplaceItem(nsIDOMSVGPathSeg *newItem,
                                            PRUint32 index,
                                            nsIDOMSVGPathSeg **_retval)

  InsertElementAt(newItemSeg, index);
  NS_ADDREF(*_retval = newItem);

  return NS_OK;

During execution of |InsertElementAt| "DOMAttrModified" event is dispatched. User's provided event handler will be called. During that callback it is possible to delete whole content of |mSegments|, e.g. by calling method clear() on pathSegList object. As |mSegments| is defined as |nsCOMArray| and method |ObjectAt| does not do out-of-bound check of index argument, previously |ObjectAt| freed memory will be referenced.

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

This vulnerability was discovered by:
    * regenrecht
provisionally "critical" based on reputation, but looks like the PoC got stripped in mail.
Whiteboard: [sg:critical?]

Comment 2

7 years ago
I've sent mail to the reporter requesting a re-send of the PoC.
Created attachment 524301 [details]
PoC (try 2)


6 years ago
Assignee: nobody → jwatt

Comment 4

6 years ago
Classes that have this bug:


Classes that do NOT have this bug:

  nsSVGLengthList - ReplaceItem() not implemented
  nsSVGPointList - ReplaceItem() not implemented
  nsSVGTransformList - Different implementation

Comment 5

6 years ago
Created attachment 525534 [details] [diff] [review]
Attachment #525534 - Flags: review?(dholbert)
Comment on attachment 525534 [details] [diff] [review]

> nsSVGNumberList::ReplaceItem(nsIDOMSVGNumber *newItem,
>                              PRUint32 index,
>                              nsIDOMSVGNumber **_retval)
> {
>-  nsresult rv = RemoveItem(index, _retval);
>-  if (NS_FAILED(rv))
>-    return rv;
>+  if (index >= mNumbers.Length()) {
>+  }
>-  return InsertElementAt(newItem, index);
>+  WillModify();
>+  NS_RELEASE(mNumbers[index]);
>+  mNumbers[index] = newItem;
>+  NS_ADDREF(newItem);
>+  DidModify();

This ^ is a bit hard to parse.  Could you add a comment saying something like:
> // This is equivalent to RemoveItem() followed by InsertElementAt(), but
> // with the WillModify() / DidModify() notifications collapsed.

r=dholbert either way
Attachment #525534 - Flags: review?(dholbert) → review+


6 years ago
Attachment #525534 - Flags: approval1.9.2.17?


6 years ago
blocking1.9.1: --- → .20+
blocking1.9.2: --- → .18+

Comment 7

6 years ago
What's the procedure for landing this on 1.9.1 and 1.9.2? I now have patches for both ready to push.

Comment 8

6 years ago
Comment on attachment 525534 [details] [diff] [review]

Granting approval for and (assuming the same patch applies there) for release-drivers.
Attachment #525534 - Flags: approval1.9.2.18+
Attachment #525534 - Flags: approval1.9.2.17?
Attachment #525534 - Flags: approval1.9.1.20+

Comment 9

6 years ago
Does approval mean I should push directly to 1.9.1 and 1.9.2, or is there some sort of shadow repo that I should be pushing to?

Comment 10

6 years ago
(In reply to comment #8)
> [snip] (assuming the same patch applies there) [snip]

The patch needs to be tweaked slightly, but it's essentially the same.

Comment 11

6 years ago
Daniel, can I direct comment 9 at you, or ask you to get the appropriate person to comment? Apparently security bugs aren't watched as closely as I expected so asking the wind doesn't work.
Yes, please check approved patches directly into their respective branches. (shadow repo will be for trunk, as a holding pen until branch patches are ready)


6 years ago
tracking-firefox5: --- → +
jst marked this tracking-firefox5+ but the version field says "1.9.2". Does this bug affect mozilla-central/aurora?
jwatt - jst's out for a while, can you tell us whether this impacts aurora as well? If so, can you request approval-aurora and land it there when you land it elsewhere?
status1.9.1: --- → wanted
status1.9.2: --- → wanted
status-firefox5: --- → affected
I'll defer to jwatt for the definitive answer, but AFAIK this doesn't affect Aurora / Firefox 5.  (nor does it affect Firefox 4)

The classes in question (comment 4) were completely rewritten after gecko 1.9.2

Comment 16

6 years ago
(In reply to comment #3)
> Created attachment 524301 [details]
> PoC (try 2)

This .zip is password protected, so I can't access it.

Comment 17

6 years ago
(In reply to comment #13)
> jst marked this tracking-firefox5+ but the version field says "1.9.2". Does
> this bug affect mozilla-central/aurora?

No. It only affects 1.9.2 and earlier.


6 years ago
status-firefox5: affected → unaffected
tracking-firefox5: + → -

Comment 18

6 years ago
Pushed http://hg.mozilla.org/releases/mozilla-1.9.2/rev/14dbc2f02f79
Pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/e97fac945e09
Last Resolved: 6 years ago
Resolution: --- → FIXED
status1.9.1: wanted → .20-fixed
status1.9.2: wanted → .18-fixed
status2.0: --- → unaffected
Loading the PoC in, I get this crash: https://crash-stats.mozilla.com/report/index/43e40b3b-5762-4707-8995-165692110607

In (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110607 Namoroka/3.6.18pre (.NET CLR 3.5.30729)), I get no crash and the PoC renders.

This looks to be fixed in 1.9.2.
Keywords: verified1.9.2
Alias: CVE-2011-0083
Group: core-security
You need to log in before you can comment on or make changes to this bug.