Closed Bug 1343212 Opened 3 years ago Closed 3 years ago
Crashing with file input dialog
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 Build ID: 20161229190117 Steps to reproduce: Opening the attached testcase with pop-ups allowed. domFuzzLite3.xpi add-on helps on reproducing. Tested with a Nightly build 32bit version: Name Firefox Version 54.0a1 Build ID 20170213030206 Stack traces from windbg attached. Actual results: (a84.a8c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=21708c78 ebx=75058940 ecx=003aea90 edx=00000000 esi=003aea90 edi=75193008 eip=74d44295 esp=003aea50 ebp=003aea68 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210206 SHLWAPI!IUnknown_QueryService+0x2f: 74d44295 8b08 mov ecx,dword ptr [eax] ds:002b:21708c78=????????
I can't reproduce even after repeatedly refreshing the test page. I then realized the testcase calls window.close() which will only work if you open the window from script, so I did that a few times (window.open(..., "_blank") from the js console), and still no crashes. In your case, can you reproduce reliably? What Windows version are you using? Can you reproduce on other OSes? Do I need to select a file in the file upload dialog, or click cancel, or something else? None of this is in the STR so I'm just guessing at this point... The stack from windbg looks odd (in particular, it looks vaguely like you tried to quit Firefox at some point and then kept it open after all) and looks like it's crashing in windows code... Jim, can you make something of this?
(In reply to :Gijs from comment #2) In fact I can't make it to reproduce with a freshly created profile, tried with windows x86 and linux x64, my testing profile had a user.js and preference by removing it the debugger and the ASAN build stopped reproducing the memory corruption. I'm getting a tab crash though in a new clean profile, by using a second html that opens the same test.html file as a pop-up. Only using the domFuzzLite3.xpi add-on and allowing pop-ups, no need to click the dialog the tab is supposed to vanish right away and I did receive this message on the console: ###!!! [Parent][DispatchAsyncMessage] Error: PFilePicker::Msg_Open Route error: message sent to unknown actor ID [Parent 28210] WARNING: pipe error (72): Connection reset by peer: file /home/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 346 [Parent 28210] WARNING: pipe error (55): Connection reset by peer: file /home/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 346 [Parent 28210] WARNING: pipe error (80): Connection reset by peer: file /home/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 346 ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0082,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv But no longer memory corruption reports, perhaps it really was something happening because of my user.prefs. I'm attaching the html that opens the test.html just in case.
Attachment #8841960 - Attachment description: test.html → test.html (requires domFuzzlite add-on)
Group: firefox-core-security → core-security
Component: Untriaged → DOM
Product: Firefox → Core
Kamil: please try reproducing. I think you'll need one of the fuzz-team's addons for the missing functions.
Using the STR that I've listed below, I've managed to reproduce the following tab crash on all three platforms: * bp-15ab5221-8d4e-4ce7-9966-50f0a2170321 [Windows 10 Pro x64 VM] * bp-7922848f-8106-4217-8d37-1a22f2170321 [macOS 10.12.3 x64] * bp-09c3c104-3b18-40ed-bc8c-dacc42170321 [Ubuntu 16.04.2 x64 VM] I've also managed to reproduce the tab crash using a debug version of m-c (using ./mach run --debug) but I didn't really get any meaningful information other than the following errors which look similar to what Filipe mentioned in comment#3: [Parent 44962] WARNING: Unable to retrieve the tooltip node document.: file /Users/kjozwiak/projects/mozilla-central/layout/xul/nsXULTooltipListener.cpp, line 578 ###!!! [Parent][DispatchAsyncMessage] Error: PFilePicker::Msg_Open Route error: message sent to unknown actor ID ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0080,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv Running the test cases on a m-c asan build under Ubuntu 16.04.2 LTS will produce the following errors the terminal once the tab crashes: ###!!! [Parent][DispatchAsyncMessage] Error: PFilePicker::Msg_Open Route error: message sent to unknown actor ID [Parent 25279] WARNING: pipe error (50): Connection reset by peer: file /home/kjozwiak/code/asan-m-c/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 346 [Parent 25279] WARNING: pipe error (72): Connection reset by peer: file /home/kjozwiak/code/asan-m-c/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 346 ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0080,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv However, I didn't receive any access violation crashes when going through the STR. I've must have run each test case at least 30 times on each platform and I keep getting the same tab crashes that I mentioned above. STR Used: * install the latest version of m-c * xpinstall.signatures.required;false under about:config and install domFuzzLite3.xpi (restart required) * open either test.html (comment#1) or popup.html (comment#4) and allow popups from that specific file * refresh the page several times and eventually you'll run into the above tab crashes
On the Windows side of things, we're just caught up in a standard dispatch call. In felipe's stack we're in windows code. I don't see anything interesting here.
OS: Unspecified → All
Hardware: Unspecified → All
Andrea, do you have some ideas here? Maybe we could fix this crash, though it sounds like maybe it isn't exploitable.
It seems a bug in the PFilePicker. I'm dubgging it.
Assignee: nobody → amarchesini
Attachment #8853056 - Flags: review?(continuation) → review+
Thanks for looking at this. I guess we can unhide it? Sending a message to a dead actor isn't a security issue, I think.
I guess so. Can you unhide it? I'll land the patch in the meantime.
Flags: needinfo?(filipesw) → needinfo?(continuation)
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/6f7b3c6fd947 FilePicker child actor must not send Open() if it has been already distroyed, r=mccr8
You need to log in before you can comment on or make changes to this bug.