Exploitable crash in Flash | [@ nsPluginStreamListenerPeer::OnDataAvailable ]

RESOLVED DUPLICATE of bug 747066

Status

()

--
critical
RESOLVED DUPLICATE of bug 747066
6 years ago
4 years ago

People

(Reporter: bc, Assigned: benjamin)

Tracking

(Blocks: 1 bug, 5 keywords)

Trunk
x86_64
Windows 7
crash, reproducible, sec-critical, testcase, verifyme
Points:
---

Firefox Tracking Flags

(firefox19+ fixed, firefox20+ fixed)

Details

(Whiteboard: [adv-main19-], URL)

Attachments

(4 attachments)

(Reporter)

Description

6 years ago
Created attachment 684036 [details]
nsPluginStreamListenerPeer::OnDataAvailable crash report

1. http://www.orchlon.mn/web/guest ( I removed the sessionid in case it is needed I have it)
2. Crash Windows and sometimes Linux

In crash automation I hit several crashes.

One was flagged by breakpad's tool as exploitable:

nsPluginStreamListenerPeer::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned __int64, unsigned int) mozilla::net::nsHttpChannel::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned __int64, unsigned int) nsInputStreamPump::OnStateTransfer() nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) nsInputStreamReadyEvent::Run()

EXCEPTION_ACCESS_VIOLATION_EXEC	
0xffffffffdddddddd

Operating system: Windows NT
                  6.1.7601 Service Pack 1
CPU: x86
     GenuineIntel family 6 model 37 stepping 1
     2 CPUs

Crash reason:  EXCEPTION_ACCESS_VIOLATION_EXEC
Crash address: 0xffffffffdddddddd

Thread 0 (crashed)
 0  0xdddddddd
    eip = 0xdddddddd   esp = 0x0031d3bc   ebp = 0x0031d4c0   ebx = 0x00000000
    esi = 0x0033c2c0   edi = 0x00000000   eax = 0xdddddddd   ecx = 0x068e8464
    edx = 0x068e8104   efl = 0x00010202
    Found by: given as instruction pointer in context

An EXEC violation at a deleted address is a Bad Thing(tm).

Linux crashed at

mozalloc_abort | Abort | NS_DebugBreak_P | mozilla::plugins::PluginModuleParent::StreamCast mozilla::plugins::PluginModuleParent::NPP_WriteReady nsNPAPIPluginStreamListener::OnDataAvailable nsPluginStreamListenerPeer::OnDataAvailable mozilla::net::nsHttpChannel::OnDataAvailable

with ABORT: Corrupted plugin stream data.

Windows also hit a plugin crash at:
F21225463__________________________________________________________________________________________________________ F1717497556________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ F1470906166_________________________________________________ F_1513036030________________________________________ F_424569316__________________________________________________


Running the site on Windows 7 64bit with Windgb and !exploitable hit:

(ad4.b5c): Access violation - code c0000005 (!!! second chance !!!)
eax=6bfab536 ebx=fffde000 ecx=001d07e0 edx=0062b3c4 esi=00000005 edi=0062b194
eip=6bfab536 esp=004cfd54 ebp=004cfd6c iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
<Unloaded_NPSWF32_11_5_502_110.dll>+0x6bb536:
6bfab536 ??              ???
1:023> !load winext/msec.dll
1:023> !exploitable
*** ERROR: Module load completed but symbols could not be loaded for plugin-container.exe
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - Data Execution Prevention Violation starting at <Unloaded_NPSWF32_11_5_502_110.dll>+0x00000000006bb536 (Hash=0x1b0a6843.0x09245e48)

User mode DEP access violations are exploitable.
(Reporter)

Comment 1

6 years ago
Created attachment 684037 [details]
mozalloc_abort crash report
(Reporter)

Comment 2

6 years ago
Created attachment 684039 [details]
NPSWF32_11_5_502_110.dll!F21225463 crash report
(Reporter)

Comment 3

6 years ago
Created attachment 684053 [details]
testcase
(Reporter)

Comment 4

6 years ago
Loading this in Nightly debug under windbg shows the exploitable crash on shutdown.
Severity: normal → critical
Keywords: reproducible, testcase
(Assignee)

Updated

6 years ago
Assignee: nobody → benjamin
Status: NEW → ASSIGNED
(Reporter)

Comment 5

6 years ago
Benjamin: I think the original exploitable crash may be related to bug 813619 and bug 747066. I can't reproduce it anymore. When it doesn't crash the site uses > 1G of memory and hits 

ABORT: State invariants violated: 'mState == FAILED || mState == STARTED || mState == CLONED', file c:/work/mozilla/builds/nightly/mozilla/widget/windows/AudioSession.cpp, line 346

The memory usage has been causing me tribbles trying to bisect. I'll try to nail it down better.

bz: Thing the original report was related to bug 747066 ?
Seems unlikely at first glance, but who knows...
Bill any thoughts on Comment 5?
status-firefox19: --- → affected
status-firefox20: --- → affected
tracking-firefox19: --- → ?
tracking-firefox20: --- → +
I think dveditz meant to + for 19 here, so doing that now.
tracking-firefox19: ? → +
Given what we now know about bug 747066, it seems entirely possible that this was caused by it.

Comment 10

6 years ago
(In reply to Bill McCloskey (:billm) from comment #9)
> Given what we now know about bug 747066, it seems entirely possible that
> this was caused by it.

Given this is a sec-crit, does that mean we should uplift the patch from that bug?
Bug 747066 doesn't fix anything. I landed a broken version of the patch, and it caused crashes that looked like this. Then I backed it out, fixed it, and relanded. The bad code landed on 19 and was backed out of 19, so I don't think we need to worry.
Thanks Bill for clarity can you confirm if the tracking flags are correct for this bug?
It sounds like this is "fixed" in 19 and 20, by a backout of the original patch that caused the regression.
status-firefox19: affected → fixed
status-firefox20: affected → fixed
Though it would be good if that was verified on 19 and 20.
Keywords: verifyme
(Reporter)

Comment 15

6 years ago
I've attempted to reproduce using local builds on Windows and was unable to do so. I also have submitted the original url to automation and it has completed testing with Windows XP and Windows 7 and did not reproduce either version of the crash. I'd like to call this fixed by Bug 747066 and open it up. Bill, does that sound right?
That sounds good to me.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 747066
Whiteboard: [adv-main19-]
Group: core-security
You need to log in before you can comment on or make changes to this bug.