Closed Bug 1616909 Opened 4 years ago Closed 4 years ago

Hazard Introduced by SourceExtent

Categories

(Core :: JavaScript Engine, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla75
Tracking Status
firefox-esr68 --- unaffected
firefox73 --- unaffected
firefox74 --- unaffected
firefox75 --- fixed

People

(Reporter: mgaudet, Assigned: mgaudet)

References

(Regression)

Details

(Keywords: csectype-uaf, regression, sec-high, Whiteboard: [post-critsmash-triage])

Attachments

(1 file)

It appears that as part of my SourceExtent Patch (Bug 1615728) I introduced a GC hazard

The issue is as follows:

  1. In JSScript::CreateFromLazy we call JSScript::New(cx, fun, sourceObject, lazy->extent()); lazy->extent() returns a reference to the member extent_ of the correctly rooted LazyScript lazy.
  2. Inside JSScript::New we call Allocate, then invoke the JSScript constructor on the returned memory, with the extent reference that was passed in.
  3. When Allocate is called, lazy gets moved; and the reference now points to deallocated memory.

I'm going to mark this as a secure bug; I'm not entirely sure of the security implications here, and given it's only been on nightly for less than 24 hours it's not high sev, but it's an issue.

On my local build I can reproduce this trivally by running central with the anyref-val-tracing test.

Assignee: nobody → mgaudet
Status: NEW → ASSIGNED
Group: core-security → javascript-core-security

For the few times we return references or pointers to fields of GC things, the quick & dirty technique is to change the accessor signature to require an AutoRequireNoGC& parameter. It doesn't fully prevent problems, but at least makes the caller create (probably) an AutoCheckCannotGC on the stack and thus think about the live range and where GC is possible.

...but of course, you have to know about the potential for problems in order to know to do something like that, and I've got nothing for that.

(And your fix here is definitely better; if you can get away with copying, it's safer and easier to use.)

I opened Bug 1616926 as a potential road for us to get a simple static analysis that helps prevent cases like this.

Priority: -- → P1
Group: javascript-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla75
Flags: qe-verify-
Whiteboard: [post-critsmash-triage]
Group: core-security-release
Has Regression Range: --- → yes
Keywords: regression
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: