Closed Bug 1545733 Opened 5 years ago Closed 2 years ago

null pointer crash @ mozilla::dom::WorkerPrivate::Notify(mozilla::dom::WorkerStatus)

Categories

(Core :: DOM: Workers, defect, P3)

Product:
Core
Component:
DOM: Workers
Version:
66 Branch
Platform:
Unspecified
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
100 Branch
Tracking Flags:
Tracking Status
firefox100 --- fixed

People

(Reporter: hmali201488, Assigned: edenchuang)

References

(Depends on 1 open bug)

Details

Crash Data

Attachments

(4 files)

POC video and the payload pdf file
1.93 MB, application/x-rar
Details
crash_report.rar
398.76 KB, application/octet-stream
Details
crash_firefox.rar
4.45 MB, application/octet-stream
Details
Bug 1545733 - Don't call WorkerPrivate::Cancel() in RemoteWorkerChild::CloseWorkerOnMainThread() if RemoteWorkerChild::mState(Pending).mWorkerPrivate is nullptr. r=#dom-worker-reviewers
48 bytes, text/x-phabricator-request
Details | Review

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)

Flags: needinfo?(hmali201488)

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

Flags: needinfo?(hmali201488)
Attached file crash_report.rar —

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.

Flags: needinfo?(hmali201488)
Attached file crash_firefox.rar —

New Profiles Crash

Flags: needinfo?(hmali201488)

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.

Crash Signature: [@ mozilla::dom::WorkerPrivate::Notify ]
Component: Untriaged → Widget: Gtk
Flags: needinfo?(stransky)
Flags: needinfo?(hmali201488)
Product: Firefox → Core

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

Component: Widget: Gtk → DOM: Workers
Flags: needinfo?(stransky)
Summary: FireFox Daniel of Service → null pointer crash @ 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

Flags: needinfo?(hmali201488)
Priority: -- → P2
See Also: → 1539508
See Also: → 1624569
Depends on: 1539508
Priority: P2 → P3
See Also: 1539508 →
See Also: → 1619923

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

Flags: needinfo?(jstutte)
Severity: normal → S4
Flags: needinfo?(jstutte)
Crash Signature: [@ mozilla::dom::WorkerPrivate::Notify ] → [@ mozilla::dom::WorkerPrivate::Notify ] [@ mozilla::dom::RemoteWorkerChild::CloseWorkerOnMainThread(mozilla::Variant<mozilla::dom::RemoteWorkerChild::Pending, mozilla::dom::RemoteWorkerChild::Running, mozilla::dom::RemoteWorkerChild::PendingTerminated, m…
Crash Signature: , mozilla::dom::RemoteWorkerChild::Terminated>&)] → , mozilla::dom::RemoteWorkerChild::Terminated>&)] [@ mozilla::dom::WorkerPrivate::Notify(mozilla::dom::WorkerStatus)]

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?

Crash Signature: [@ mozilla::dom::WorkerPrivate::Notify ] [@ mozilla::dom::RemoteWorkerChild::CloseWorkerOnMainThread(mozilla::Variant<mozilla::dom::RemoteWorkerChild::Pending, mozilla::dom::RemoteWorkerChild::Running, mozilla::dom::RemoteWorkerChild::PendingTerminated, m… → [@ mozilla::dom::WorkerPrivate::Notify ] [@ mozilla::dom::RemoteWorkerChild::CloseWorkerOnMainThread(mozilla::Variant<mozilla::dom::RemoteWorkerChild::Pending, mozilla::dom::RemoteWorkerChild::Running, mozilla::dom::RemoteWorkerChild::PendingTerminated, …
Flags: needinfo?(ytausky)
Flags: needinfo?(ytausky) → needinfo?(jstutte)
Crash Signature: , mozilla::dom::RemoteWorkerChild::Terminated>&)] [@ mozilla::dom::WorkerPrivate::Notify(mozilla::dom::WorkerStatus)] → , mozilla::dom::RemoteWorkerChild::Terminated>&)] [@ mozilla::dom::WorkerPrivate::Notify(mozilla::dom::WorkerStatus)] [@ RefPtr<mozilla::dom::WorkerPrivate>::operator->() const]
Crash Signature: , mozilla::dom::RemoteWorkerChild::Terminated>&)] [@ mozilla::dom::WorkerPrivate::Notify(mozilla::dom::WorkerStatus)] [@ RefPtr<mozilla::dom::WorkerPrivate>::operator->() const] → , mozilla::dom::RemoteWorkerChild::Terminated>&)] [@ mozilla::dom::WorkerPrivate::Notify(mozilla::dom::WorkerStatus)] [@ RefPtr<mozilla::dom::WorkerPrivate>::operator->() const]
Flags: needinfo?(jstutte) → needinfo?(echuang)
See Also: → 1749068

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.

Flags: needinfo?(jstutte)
Flags: needinfo?(jstutte)

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

Flags: needinfo?(jstutte)

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().
Flags: needinfo?(jstutte)
Flags: needinfo?(echuang)
Assignee: nobody → echuang
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Pushed by echuang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4556eb029348
Don't call WorkerPrivate::Cancel() in RemoteWorkerChild::CloseWorkerOnMainThread() if RemoteWorkerChild::mState(Pending).mWorkerPrivate is nullptr. r=dom-worker-reviewers,jstutte

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

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox100: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch

Hi Atila,

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

Best Regards,
Hamid

Flags: needinfo?(abutkovits)

Hi Hamid,

I am not sure how to do this.

Aryx, could you help us out?

Thanks

Flags: needinfo?(abutkovits) → needinfo?(aryx.bugmail)

(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?

Flags: needinfo?(aryx.bugmail) → needinfo?(tom)

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.

Flags: needinfo?(tom)

Thanks Tom for your response.

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

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: