The default bug view has changed. See this FAQ.
Bug 433610 (CVE-2008-5013)

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

VERIFIED FIXED

Status

()

Core
Plug-ins
VERIFIED FIXED
9 years ago
2 years ago

People

(Reporter: bsterne, Assigned: jst)

Tracking

({verified1.8.1.18})

1.8 Branch
x86
Windows XP
verified1.8.1.18
Points:
---
Bug Flags:
blocking1.8.1.18 +
wanted1.8.1.x +
blocking1.8.0.next +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical])

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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.
(Reporter)

Updated

9 years ago
Whiteboard: [sg:investigate]
(Reporter)

Comment 3

9 years ago
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

9 years ago
same thing in safari Version 3.1.1 (5525.18)

Comment 6

9 years ago
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

9 years ago
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.
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
Flags: blocking1.8.1.15?
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

9 years ago
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

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

Comment 12

9 years ago
my linux set up is using flash 9.0 r124
If you can crash on Mac, the OS crash reports are often very handy. I'll try and reproduce this evening.

Comment 14

9 years ago
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.

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.
Assignee: nobody → jst
Whiteboard: [sg:investigate] → [sg:critical]
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.
Alias: ZDI-CAN-259
Summary: Investigate ZDI-CAN-259: Possible buffer overflow in Flash plugin → Mozilla Firefox Flash Player Dynamic Module Unloading Vulnerability

Comment 17

9 years ago
seems like we should get this on the radar for fx3 as well unless we have confirmed that it is ok.  
Flags: blocking1.9?
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.
Whiteboard: [sg:critical] → [sg:critical vector] flash's bug?
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

9 years ago
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

9 years ago
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

9 years ago
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?
> 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

9 years ago
I think the mozilla.org confidential thing was a mistake when the bug got filed.  removing..
Group: mozillaorgconfidential

Comment 25

9 years ago
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.
Flags: blocking1.9?
Flags: blocking1.8.1.15? → blocking1.8.1.15+
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');
  }
Flags: blocking1.8.1.15+ → blocking1.8.1.15?
Flags: blocking1.8.1.15? → blocking1.8.1.15+
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.
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.16?
Flags: blocking1.8.1.15+
Version: unspecified → 1.8 Branch
Flags: blocking1.8.1.17? → blocking1.8.1.17+
Whiteboard: [sg:critical vector] flash's bug? → [sg:critical]
(Assignee)

Comment 28

9 years ago
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.
Attachment #335479 - Flags: superreview?(bzbarsky)
Attachment #335479 - Flags: review?(bzbarsky)
Whiteboard: [sg:critical] → [sg:critical] needs r/sr=bzbarsky
Boris said he wouldn't have time to review this before freeze. Pushing out to 1.8.1.18...
Flags: blocking1.8.1.17+ → blocking1.8.1.18+
Comment on attachment 335479 [details] [diff] [review]
Proposed fix.

Looks good.  Sorry for the lag!
Attachment #335479 - Flags: superreview?(bzbarsky)
Attachment #335479 - Flags: superreview+
Attachment #335479 - Flags: review?(bzbarsky)
Attachment #335479 - Flags: review+
Can this land?  Would be killer sad to miss 1.8.1.18!
Whiteboard: [sg:critical] needs r/sr=bzbarsky → [sg:critical] needs checkin
(Assignee)

Comment 32

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

Yes, this should be ready to land.
Attachment #335479 - Flags: approval1.8.1.18?
Attachment #335479 - Flags: approval1.8.1.18? → approval1.8.1.18+
Comment on attachment 335479 [details] [diff] [review]
Proposed fix.

Approved for 1.8.1.18, a=dveditz for release-drivers
(Assignee)

Comment 34

9 years ago
Fix landed on the 1.8 branch.
Keywords: fixed1.8.1.18
(Assignee)

Comment 35

9 years ago
Closing bug, as this was a 1.8 only issue.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: [sg:critical] needs checkin → [sg:critical]
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.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1.18 → verified1.8.1.18

Updated

9 years ago
Attachment #335479 - Flags: approval1.8.0.15+

Comment 37

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

a=asac for 1.8.0 branch
Alias: ZDI-CAN-259 → CVE-2008-5013
Summary: Mozilla Firefox Flash Player Dynamic Module Unloading Vulnerability → Mozilla Firefox Flash Player Dynamic Module Unloading Vulnerability (zdi-can-259)
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

Updated

8 years ago
Flags: blocking1.8.0.next+
Depends on: 472344
Group: core-security
Summary: Mozilla Firefox Flash Player Dynamic Module Unloading Vulnerability (zdi-can-259) → Mozilla Firefox Flash Player Dynamic Module Unloading Vulnerability (ZDI-CAN-259)
You need to log in before you can comment on or make changes to this bug.