User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36

Steps to reproduce:

1. Create a PDF file that contains XSS payload
2. Name it as shown in the video/poc
3. Open the Firefox then open the folder that contain the pdf file.

Actual results:

During my pen-testing process on one of the bug bounty program, I've noticed that the Firefox browser has been crashed when I was trying to open a simple PDF file; however this file name contain an XSS payload which crashed the Firefox once I've tried to open even the folder it self.

Expected results:

There is no direct impact on the user, however this could be lie under the Daniel of Service category since the user will don't be able to open any file inside the folder that includes the payload file as you see in the attached video[poc]

Please note that, this vulnerability is only works on Linux. I've tested on Windows and didn't work.
Best Regards,
Hamid

I've tried the STR as detalied in comment0 using 66.0.3 20190409155332 and 68.0a1 20190422214919 and I couldn't reproduce the shown result (Fx crashing).

Hamid, could you please try reproducing the crash on a clean profile?
Also, it would really be useful if you could share the crash reports. (you can find them opening a new tab and type about:crashes)

Thanks for your response Alin,
I can still reproduce it as you see in the attached evidence, also have uploaded the crash report.
Please let me know if you need further information.
Best Regards,
Hamid

Kindly find attached the Crash Report.

Hi Team,
Please let me know if you need further information.
Best regards
Hamid

Hi Team,

This comment is just to follow up with you if you need any further information and/or feedback me with the latest status.

Have a good one.

Hamid

Thanks Hamid for all the info, however, we cannot reproduce this issue with a new profile. Can you please confirm that you can reproduce this issue with a new profile and the attached .pdf testcase?

In the original screen recording, seems that you have a few extensions installed, which might make the difference between reproducing or not.

New Profiles Crash

Hi Adrian,

Thanks for your message, I've uploaded the PDF and the PoC video for multiple crashes for 3 profiles.

Please let me know if you need further information.

Best Regards,
Hamid

Hamid, I still cannot reproduce with the latest versions(68/70) or the one the bug was reported against(66 / 65.0) on Ubuntu 16.04.

Could you please check and list what the folder permissions are for the folder you are crashing against?
The crash report attached in comment 4 is: https://crash-stats.mozilla.org/report/index/4b52f0da-6f8f-48d5-a42f-bebdf0190423

It is not excluded that this is something particular to Kali distro you're using. Do you have any means to reproduce this on a different distro?

Martin, do you by chance have any clue on what's going on here? I'm going to triage this issue for the time beeing against Widget::Gtk in lack of a better idea.

Looks like WorkerPrivate is null at mozilla::dom::RemoteWorkerChild::CloseWorkerOnMainThread() / mozilla::dom::WorkerPrivate::Notify(mozilla::dom::WorkerStatus).

Hi Adrian,

Thanks for your message.

I've reproduced this PoC on Kali, Ubuntu and MacOS; however, the crash only worked on Kali.

Please let me know if you need further information.
Thanks,
Hamid

Hi Team,
Just following up this ticket. Is there anything that I can do to proceed further?
Thanks,
Hamid

Looking at RemoteWorkerChild::RemoteWorkerChild it seems we create a RemoteWorkerChild with mState(VariantType<Pending>(), "RemoteWorkerChild::mState") which in turn initializes mWorkerPrivate to nullptr. If (for whatever reason) we receive a RemoteWorkerChild::CloseWorkerOnMainThread early enough we would find mWorkerPrivate still being nullptr.

On the call-stack I see RemoteWorkerChild::SharedWorkerOp::MaybeStart which might indicate to be in an early initialization state?

The severity field for this bug is relatively low, S4. However, the bug has 7 duplicates.
:jstutte, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Hi Jens,

This is just a following up comment. Is there anything that you need from myself to proceed with this process?

Best Regards,
Hamid

This looks like a case that executing a terminate operation during launching a shared worker.

According to https://searchfox.org/mozilla-central/rev/840881e1232f664a58b39caaae6284c7bcf121df/dom/workers/remoteworkers/RemoteWorkerChild.cpp#863-912

SharedWorkerOp::MaybeStart would not block terminate operation while RemoteWorkerChild::mState is still pending.
And the Pending.mWorkerPrivate is still nullptr. It could be

1. The corresponding WorkerPrivate is not created.
2. The corresponding WorkerPrivate creation failed.
   But no matter which cases is, termination should not call Pending.mWorkerPrivate->Cancel().

https://hg.mozilla.org/mozilla-central/rev/4556eb029348

Hi Atila,

I'm glad this issue has been fixed. Is it possible to get a CVE for this bug?

Best Regards,
Hamid

Hi Hamid,

I am not sure how to do this.

Aryx, could you help us out?

Thanks

(In reply to Hamid Mahmoud from comment #34)

I'm glad this issue has been fixed. Is it possible to get a CVE for this bug?

We don't issue CVEs for issues that are not considered vulnerabilities; and this issue does not represent a security vulnerability - only a tab crash, which doesn't rate high in the DoS possibilities.

Thanks Tom for your response.

What I was noticing is a "whole browser crash" and not just tab crash.