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.
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.
same thing in safari Version 3.1.1 (5525.18)
on a windows xp VM Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/2008020121 Firefox/126.96.36.199 the POC page runs a lot slower. The HTML content is shown, then the dialogs, but then firefox crashes...
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 188.8.131.52 and older FF184.108.40.206 (just in case) and Flash 9.0r115 and 9.0r124
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.
on Firefox/220.127.116.11 I can consistantly get a crash, but I can't get talkback to launch so we could get a stack trace.
also crash on linux (ubuntu) w/ 18.104.22.168 but can't get talkback there either.
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.
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 22.214.171.124pre and older Firefox 126.96.36.199. 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.
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.
seems like we should get this on the radar for fx3 as well unless we have confirmed that it is ok.
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.
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?
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
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
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?
I think the mozilla.org confidential thing was a mistake when the bug got filed. removing..
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.
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.
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.
Boris said he wouldn't have time to review this before freeze. Pushing out to 188.8.131.52...
Comment on attachment 335479 [details] [diff] [review] Proposed fix. Looks good. Sorry for the lag!
Can this land? Would be killer sad to miss 184.108.40.206!
Comment on attachment 335479 [details] [diff] [review] Proposed fix. Yes, this should be ready to land.
Comment on attachment 335479 [details] [diff] [review] Proposed fix. Approved for 220.127.116.11, a=dveditz for release-drivers
Fix landed on the 1.8 branch.
Closing bug, as this was a 1.8 only issue.
This crashed 18.104.22.168 when I tested it but does not crash the 22.214.171.124pre nightly builds. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199pre) Gecko/2008102103 BonEcho/188.8.131.52pre Marking verified.