433610 - (CVE-2008-5013) Mozilla Firefox Flash Player Dynamic Module Unloading Vulnerability (ZDI-CAN-259)

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Brandon Sterne (:bsterne)]

Attachment: Vulnerability write-up

Tipping Point has reported a bug in the Flash plugin for Firefox which they claim contains a buffer overflow.  This could potentially allow an attacker to execute arbitrary code on victim's computer.  I have not been able to confirm or reproduce the bug yet, and it would be great if we can get confirmation from someone in the Security Group.

Attached is the vulnerability summary submitted by the Tipping Point researcher, Cameron Hotchkies.  I will also attach the proof-of-concept materials shortly.

Comment 3

[Brandon Sterne (:bsterne)]

I am reaching out to the researcher to find out what specific Firefox and Flash versions he is using in his proof-of-concept.  I'll update the bug when I find out.

Comment 5

[chris hofmann]

same thing in safari Version 3.1.1 (5525.18)

Comment 6

[chris hofmann]

on a windows xp VM

Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/2008020121 Firefox/2.0.0.12

the POC page runs a lot slower.  The HTML content is shown, then the dialogs, but then firefox crashes...

Comment 7

[chris hofmann]

on the same vm with

Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0

    File name: NPSWF32.dll
    Shockwave Flash 9.0 r115

the POC seems to run *alot slower*. Firefox becomes unresponsive for several minutes at a time, but the dialogs do come up, and I haven't seen the crash yet.

Comment 8

[Daniel Veditz [:dveditz]]

It's not yet clear this is a Firefox bug: neither Brandon nor I have been able to reproduce and the advisory text mentions "vulnerable installations of Adobe's Flash Player", possibly implying other versions are not vulnerable. Have requested more information from TippingPoint about the exact versions of Firefox and Flash they're reporting.

If this is not a problem in more recent Flash versions it could well be an aspect of one of the recent Adobe security fixes.

Personally I tried FF 2.0.0.14 and older FF2.0.0.5 (just in case) and Flash 9.0r115 and 9.0r124

Comment 9

[Daniel Veditz [:dveditz]]

Ok, I take that back. When I load the poc from a webserver (as in chofmann's link) instead of local disk I see a crash. Not sure why that would matter for Firefox or Flash but at least it's progress.

Comment 10

[chris hofmann]

on Firefox/2.0.0.12 I can consistantly get a crash, but I can't get talkback to launch so we could get a stack trace.

Comment 11

[chris hofmann]

also crash on linux (ubuntu) w/ 2.0.0.14  but can't get talkback there either.

Comment 12

[chris hofmann]

my linux set up is using flash 9.0 r124

Comment 13

[Samuel Sidler (old account; do not CC)]

If you can crash on Mac, the OS crash reports are often very handy. I'll try and reproduce this evening.

Comment 14

[chris hofmann]

so maybe what I'm seeing is not a crash...  on linux this is the tail of what gdb kicks out before firefox "disappears"

###!!! ASSERTION: cannot call on a dirty frame not currently being reflowed: '!NS_SUBTREE_DIRTY(this) || (GetStateBits() & NS_FRAME_IN_REFLOW)', file /home/chofmann/builds/trunk/mozilla/layout/generic/nsFrame.cpp, line 556
###!!! ASSERTION: cannot call on a dirty frame not currently being reflowed: '!NS_SUBTREE_DIRTY(this) || (GetStateBits() & NS_FRAME_IN_REFLOW)', file /home/chofmann/builds/trunk/mozilla/layout/generic/nsFrame.cpp, line 556
++DOMWINDOW == 12
For application/x-shockwave-flash found plugin /home/chofmann/.mozilla/plugins/libflashplayer.so
LoadPlugin() /home/chofmann/.mozilla/plugins/libflashplayer.so returned a5a2678
[New Thread -1347433584 (LWP 13541)]
[New Thread -1355826288 (LWP 13542)]
nsPluginNativeWindowGtk2: NPPVpluginNeedsXEmbed=1
nsPluginNativeWindowGtk2: call SetWindow with xid=0x28027b5
nsPluginNativeWindowGtk2: call SetWindow with xid=0x28027b5
[Thread -1355826288 (LWP 13542) exited]
[Thread -1347433584 (LWP 13541) exited]
Killed

Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb) bt
No stack.

Comment 15

[Daniel Veditz [:dveditz]]

Argh, somehow lost an earlier modification to the bug.

I get killed by windows DEP executing in the noop slide. Definitely exploitable on versions of windows that don't support DEP by default.

For me address 0x300bee12 is consistent, both debug and optimized, latest Firefox 2.0.0.15pre and older Firefox 2.0.0.12. In the ballpark of the reporter's claimed consistent 0x300A4223... maybe the address depends on the version of Flash or specific constellation of Windows libraries or installed services.

Comment 16

[Daniel Veditz [:dveditz]]

Changing summary back to the one supplied by ZDI. For one thing that's likely how they'll refer to it when it's published, and there's no evidence of a buffer overflow per se.

Comment 17

[chris hofmann]

seems like we should get this on the radar for fx3 as well unless we have confirmed that it is ok.  

Comment 18

[Daniel Veditz [:dveditz]]

Using Safari I got shut-down by Windows DEP at the exact same 0x300bee12 address. In this case it was not in the noop slide so maybe not as reliably exploitable (or maybe needs a different heap-spray routine), but does seem to point the finger more in Flash's direction than Firefox's.

Opera also crashes (but not shut down by DEP) executing address 0x00000101.

Comment 19

[Daniel Veditz [:dveditz]]

I have not yet crashed in Firefox 3, however. Is there something we've changed in plugin handling that would mitigate this kind of plugin flaw? Is it a browser bug but Safari and Opera made the same mistake?

Comment 20

[chris hofmann]

looking at some older fx3 builds it appears the shutdown happens on fx3 beta 3

 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3]

but not fx3 beta4.   

 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4

for me beta4 and after just becomes unresponsive after the \return to 300A4223\ dialog

Comment 21

[chris hofmann]

this bug was fixed during that timeframe and it sounds a lot like what we see in running the test case.

https://bugzilla.mozilla.org/show_bug.cgi?id=410946#c4

Comment 22

[chris hofmann]

jst/boris,  what are the chances the fix for bug 410946 could help with this bug?

if it could, any thoughs on risk/difficultly in back porting to 2.x?

Comment 23

[Boris Zbarsky [:bzbarsky]]

> what are the chances the fix for bug 410946 could help with this bug?

Pretty good, if I understand this bug.  It's protecting against exactly this situation (unloading the plugin while there is plugin code on the stack).

Porting is likely to take a bit of work, since the instantiation process is quite different on branch.  But I think it should be no more risky than it was for trunk...  Which is still somewhat risky, but I think it's the most risk-free option for fixing this.

Is there a reason this bug is marked "mozilla.org Confidential", by the way?

Comment 24

[chris hofmann]

I think the mozilla.org confidential thing was a mistake when the bug got filed.  removing..

Comment 25

[chris hofmann]

removeing 1.9 blocking since it sounds like this if fixed on the trunk.  only impact on fx3 might be a possible need for a currently unplanned 2.x security fire drill release if I understand the disclosure timetable and we can't get a change to that.

Comment 26

[Daniel Veditz [:dveditz]]

For the record the decompiled flash code appears to be only a callback to the javascript routine in the page, nothing tricky:

  frame 5 {
    flash.external.ExternalInterface.call('outside_func');
  }

Comment 27

[Daniel Veditz [:dveditz]]

Backporting the trunk change (see comment 23) doesn't seem to fix the branch. Also can't reveal the bug because other vendors are affected, so we'll keep poking at this.

Comment 28

[Johnny Stenback (:jst)]

Attachment: Proposed fix.

This is a backport of the changes we took on the trunk for bug 410946. Given that our plugin initialization code is *really* different on the branch compared to trunk the changes to nsObjectFrame.cpp are not back-portable to the branch, but the changes to the plugin code alone seems to fix this particular problem. There's probably still fragility in the plugin frame code that is *not* addressed by this patch, and the only likely fix for that on the branch would be to port all the plugin loading changes from the trunk back to the branch, and that's *really* not trivial, and I would advice against investing in that given the *huge* number of regressions (and changes in functionality) we found from that change on the trunk, years after the change went in.

But this alone is a good step forward here IMO.

Comment 29

[Samuel Sidler (old account; do not CC)]

Boris said he wouldn't have time to review this before freeze. Pushing out to 1.8.1.18...

Comment 30

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 335479 [details] [diff] [review]
Proposed fix.

Looks good.  Sorry for the lag!

Comment 31

[Mike Shaver (:shaver emeritus)]

Can this land?  Would be killer sad to miss 1.8.1.18!

Comment 32

[Johnny Stenback (:jst)]

Comment on attachment 335479 [details] [diff] [review]
Proposed fix.

Yes, this should be ready to land.

Comment 33

[Daniel Veditz [:dveditz]]

Comment on attachment 335479 [details] [diff] [review]
Proposed fix.

Approved for 1.8.1.18, a=dveditz for release-drivers

Comment 34

[Johnny Stenback (:jst)]

Fix landed on the 1.8 branch.

Comment 35

[Johnny Stenback (:jst)]

Closing bug, as this was a 1.8 only issue.

Comment 36

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

This crashed 2.0.0.17 when I tested it but does not crash the 2.0.0.18pre nightly builds.

 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18pre) Gecko/2008102103 BonEcho/2.0.0.18pre

Marking verified.

Comment 37

[Alexander Sack]

Comment on attachment 335479 [details] [diff] [review]
Proposed fix.

a=asac for 1.8.0 branch

Comment 38

[Daniel Veditz [:dveditz]]

Comment on attachment 320804 [details]
Vulnerability write-up

making the original writeup private due to personal contact information we should have stripped out. The relevant public part is:

ZDI-CAN-259: Mozilla Firefox Flash Player Dynamic Module Unloading Vulnerability

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

TippingPoint has identified a vulnerability affecting the following 
products:

    Mozilla Firefox 2.0.x

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

This vulnerability allows remote attackers to execute code on vulnerable installations of Adobe's Flash Player. User interaction is required in that a user must visit a malicious web site. 

The specific flaw exists due to a failure to check whether the Flash module has been properly dynamically unloaded. If an SWF file dynamically unloads itself via an outside javascript function, the browser will return to an address no longer mapped to the Flash module. Exploitation of this vulnerability can result in arbitrary code execution under the context of the currently logged in user.

The browser seems to always return to 0x300A4223. This is reachable with a heap spray.

The problematic method used is flash.external.ExternalInterface.call("outside_func"); where outside_func is a javascript function that unloads the swf object.

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

This vulnerability was discovered by:
    * Anonymous