Closed Bug 1371865 Opened 7 years ago Closed 7 years ago

PRE_HELPER_STUB calls method on native without rooting the reflector

Categories

(Core :: XPConnect, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla56
Tracking Status
firefox-esr52 55+ fixed
firefox54 --- wontfix
firefox55 + fixed
firefox56 + fixed

People

(Reporter: mccr8, Assigned: bzbarsky)

References

Details

(Keywords: csectype-uaf, sec-critical, Whiteboard: [adv-main55-][adv-esr52.3-][post-critsmash-triage])

Attachments

(1 file, 1 obsolete file)

This is a variation on bug 1371259 for older XPConnect bindings.

This macro does:
  JSObject* unwrapped = js::CheckedUnwrap(obj, false);
  ...
  XPCWrappedNative* wrapper = XPCWrappedNative::Get(unwrapped);
  ...
  wrapper->GetScriptable()->(some function call)

The basic problem is that obj being rooted does not imply that unwrapped is rooted, so we cannot be sure that wrapper and its scriptable is rooted. At least, as far as I can tell.

This macro is used in XPC_WN_Helper_GetProperty and four other similar methods.
See Also: → CVE-2017-7801
> The basic problem is that obj being rooted does not imply that unwrapped is rooted

To be clear, this is because obj could get swapped with a dead object wrapper.
I didn't put anything in comments or the commit message explaining _why_ this should be rooted.  That's annoying, but I don't see a good way to have that documentation in there without exposing the real underlying problem.  :(
Attachment #8877714 - Flags: review?(continuation)
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #8877717 - Flags: review?(continuation)
Attachment #8877714 - Attachment is obsolete: true
Attachment #8877714 - Flags: review?(continuation)
Comment on attachment 8877717 [details] [diff] [review]
Root the unwrapped object in PRE_HELPER_STUB

[Security approval request comment]
How easily could an exploit be constructed based on the patch?  Not very.  For one thing, the set of objects that pages can access that are actually XPCWrappedNative is pretty limited.  But also, it's not immediately clear how "unwrapped" could fail to be rooted.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?  Not any more so than the actual change.

Which older supported branches are affected by this flaw?  All of them.

If not all supported branches, which bug introduced the flaw?  Effectively bug 695480.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?  This should be pretty easy and safe to backport.

How likely is this patch to cause regressions; how much testing does it need?  Not likely and not much.
Attachment #8877717 - Flags: sec-approval?
Comment on attachment 8877717 [details] [diff] [review]
Root the unwrapped object in PRE_HELPER_STUB

Review of attachment 8877717 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for fixing these bugs.
Attachment #8877717 - Flags: review?(continuation) → review+
OK, moving this patch to bug 1371259.
Depends on: CVE-2017-7801
Attachment #8877717 - Flags: sec-approval?
Fixed by bug 1371259.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Group: dom-core-security → core-security-release
Whiteboard: [adv-main55-][adv-esr52.3-]
Flags: qe-verify-
Whiteboard: [adv-main55-][adv-esr52.3-] → [adv-main55-][adv-esr52.3-][post-critsmash-triage]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: