Last Comment Bug 433610 - (CVE-2008-5013) Mozilla Firefox Flash Player Dynamic Module Unloading Vulnerability (ZDI-CAN-259)
: Mozilla Firefox Flash Player Dynamic Module Unloading Vulnerability (ZDI-CAN-...
: verified1.8.1.18
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: 1.8 Branch
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: Johnny Stenback (:jst,
: Benjamin Smedberg [:bsmedberg]
Depends on: 472344
  Show dependency treegraph
Reported: 2008-05-13 15:32 PDT by Brandon Sterne (:bsterne)
Modified: 2015-07-08 05:10 PDT (History)
21 users (show)
samuel.sidler+old: blocking1.8.1.18+
dveditz: wanted1.8.1.x+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Proposed fix. (34.79 KB, patch)
2008-08-25 21:11 PDT, Johnny Stenback (:jst,
bzbarsky: review+
bzbarsky: superreview+
dveditz: approval1.8.1.18+
Details | Diff | Splinter Review

Description Brandon Sterne (:bsterne) 2008-05-13 15:32:48 PDT
Created attachment 320804 [details]
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) 2008-05-13 16:16:01 PDT
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 2008-05-13 17:01:46 PDT
same thing in safari Version 3.1.1 (5525.18)
Comment 6 chris hofmann 2008-05-13 17:10:58 PDT
on a windows xp VM

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

the POC page runs a lot slower.  The HTML content is shown, then the dialogs, but then firefox crashes...
Comment 7 chris hofmann 2008-05-13 17:36:06 PDT
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] 2008-05-13 17:48:17 PDT
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 and older FF2.0.0.5 (just in case) and Flash 9.0r115 and 9.0r124
Comment 9 Daniel Veditz [:dveditz] 2008-05-13 17:53:56 PDT
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 2008-05-13 18:19:47 PDT
on Firefox/ 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 2008-05-13 19:42:08 PDT
also crash on linux (ubuntu) w/  but can't get talkback there either.
Comment 12 chris hofmann 2008-05-13 19:45:32 PDT
my linux set up is using flash 9.0 r124
Comment 13 Samuel Sidler (old account; do not CC) 2008-05-13 20:25:13 PDT
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 2008-05-13 20:47:55 PDT
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
For application/x-shockwave-flash found plugin /home/chofmann/.mozilla/plugins/
LoadPlugin() /home/chofmann/.mozilla/plugins/ 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]

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

Comment 15 Daniel Veditz [:dveditz] 2008-05-13 22:57:26 PDT
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 and older Firefox 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] 2008-05-13 23:05:10 PDT
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 2008-05-13 23:30:01 PDT
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] 2008-05-13 23:36:24 PDT
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] 2008-05-13 23:54:10 PDT
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 2008-05-14 07:56:28 PDT
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 2008-05-14 08:13:16 PDT
this bug was fixed during that timeframe and it sounds a lot like what we see in running the test case.
Comment 22 chris hofmann 2008-05-14 09:00:32 PDT
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 [:bz] (still a bit busy) 2008-05-14 09:41:22 PDT
> 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 " Confidential", by the way?
Comment 24 chris hofmann 2008-05-14 09:58:56 PDT
I think the confidential thing was a mistake when the bug got filed.  removing..
Comment 25 chris hofmann 2008-05-14 10:03:17 PDT
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] 2008-05-14 23:50:48 PDT
For the record the decompiled flash code appears to be only a callback to the javascript routine in the page, nothing tricky:

  frame 5 {'outside_func');
Comment 27 Daniel Veditz [:dveditz] 2008-06-05 14:51:49 PDT
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, 2008-08-25 21:11:39 PDT
Created attachment 335479 [details] [diff] [review]
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) 2008-08-26 23:27:51 PDT
Boris said he wouldn't have time to review this before freeze. Pushing out to
Comment 30 Boris Zbarsky [:bz] (still a bit busy) 2008-09-05 13:30:00 PDT
Comment on attachment 335479 [details] [diff] [review]
Proposed fix.

Looks good.  Sorry for the lag!
Comment 31 Mike Shaver (:shaver -- probably not reading bugmail closely) 2008-09-11 21:03:18 PDT
Can this land?  Would be killer sad to miss!
Comment 32 Johnny Stenback (:jst, 2008-09-12 01:19:56 PDT
Comment on attachment 335479 [details] [diff] [review]
Proposed fix.

Yes, this should be ready to land.
Comment 33 Daniel Veditz [:dveditz] 2008-09-17 14:50:02 PDT
Comment on attachment 335479 [details] [diff] [review]
Proposed fix.

Approved for, a=dveditz for release-drivers
Comment 34 Johnny Stenback (:jst, 2008-09-22 17:24:46 PDT
Fix landed on the 1.8 branch.
Comment 35 Johnny Stenback (:jst, 2008-09-24 17:02:54 PDT
Closing bug, as this was a 1.8 only issue.
Comment 36 Al Billings [:abillings] 2008-10-21 14:12:51 PDT
This crashed when I tested it but does not crash the nightly builds.

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

Marking verified.
Comment 37 Alexander Sack 2008-11-10 09:45:21 PST
Comment on attachment 335479 [details] [diff] [review]
Proposed fix.

a=asac for 1.8.0 branch
Comment 38 Daniel Veditz [:dveditz] 2008-11-20 20:42:14 PST
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 

    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"outside_func"); where outside_func is a javascript function that unloads the swf object.

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

This vulnerability was discovered by:
    * Anonymous

Note You need to log in before you can comment on or make changes to this bug.