Closed Bug 1977166 Opened 9 months ago Closed 9 months ago

Potential double free through [@ DocAccessibleParent::RecvMutationEvents]

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

RESOLVED FIXED
143 Branch
Tracking Status
firefox-esr115 142+ fixed
firefox-esr128 142+ fixed
firefox-esr140 142+ fixed
firefox140 --- wontfix
firefox141 --- wontfix
firefox142 + fixed
firefox143 + fixed

People

(Reporter: decoder, Assigned: Jamie)

Details

(4 keywords, Whiteboard: [adv-main142+r][adv-esr140.2+r][adv-esr128.14+r][adv-esr115.27+r])

Attachments

(5 files)

48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review

The IPC function DocAccessibleParent::RecvMutationEvents when triggering a ShowEvent receives a tree of AccessibleData that's used to create/arrange a tree of RemoteAccessible objects in DocAccessibleParent::ProcessShowEvent.

The RemoteAccessible parent <-> child relationship is double-linked and this code path does not validate that each child only has one parent (there is a MOZ_ASSERT(CheckDocTree()); in place but that's not sufficient as a security check).

When the content process now sends such a broken tree where one child has multiple parents and then sends a HideEvent, eventually RemoteAccessible::Shutdown() will be called twice (once for each parent) on the same RemoteAccessible causing a double free.

We have an assertion here. We should be able to fix this by adding a null return for an existing parent below that:

if (newProxy->RemoteParent()) {
  return nullptr;
}

This will cause us to fail the operation and return an IPC failure here.

Severity: -- → S2
Group: core-security → dom-core-security
Assignee: nobody → jteh
Attached file (secure)

Comment on attachment 9500470 [details]
(secure)

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: The patch does hint that there is something amiss when reusing a RemoteAccessible that still has a parent. I'm hoping this looks more like something that could result in broken behaviour, though, rather than a potential security concern.
  • Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
  • Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: all, yes
  • If not all supported branches, which bug introduced the flaw?: None
  • Do you have backports for the affected branches?: No
  • If not, how different, hard to create, and risky will they be?: This patch should apply as is to all branches, but I haven't verified that.
  • How likely is this patch to cause regressions; how much testing does it need?: Unlikely; minimal.
  • Is the patch ready to land after security approval is given?: Yes
  • Is Android affected?: Yes
Attachment #9500470 - Flags: sec-approval?

Comment on attachment 9500470 [details]
(secure)

Approved to land

Attachment #9500470 - Flags: sec-approval? → sec-approval+
Pushed by jteh@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/79144658dff0 https://hg.mozilla.org/integration/autoland/rev/a60223cb1ca3 When moving a RemoteAccessible, ensure it doesn't still have a parent. r=eeejay,decoder
Group: dom-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → 143 Branch
Keywords: ai-involved

The patch landed in nightly and beta is affected.
:Jamie, is this bug important enough to require an uplift?

For more information, please visit BugBot documentation.

Flags: needinfo?(jteh)
Attached file (secure)
Attachment #9502629 - Flags: approval-mozilla-beta?

firefox-beta Uplift Approval Request

  • User impact if declined: Potential security exploit.
  • Code covered by automated testing: no
  • Fix verified in Nightly: no
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing: not applicable
  • Risk associated with taking this patch: low
  • Explanation of risk level: Straightforward early return in a place where we already had an assertion.
  • String changes made/needed: none
  • Is Android affected?: yes
Attachment #9502629 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [sec] [qa-triage-done-c143/b142]
Flags: qe-verify-
Flags: needinfo?(jteh)
Attached file (secure)
Attachment #9503211 - Flags: approval-mozilla-esr140?

firefox-esr140 Uplift Approval Request

  • User impact if declined: Potential security exploit.
  • Code covered by automated testing: no
  • Fix verified in Nightly: no
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing: not applicable
  • Risk associated with taking this patch: low
  • Explanation of risk level: Straightforward early return in a place where we already had an assertion.
  • String changes made/needed: none
  • Is Android affected?: yes
Attached file (secure)
Attachment #9503212 - Flags: approval-mozilla-esr128?

firefox-esr128 Uplift Approval Request

  • User impact if declined: Potential security exploit.
  • Code covered by automated testing: no
  • Fix verified in Nightly: no
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing: not applicable
  • Risk associated with taking this patch: low
  • Explanation of risk level: Straightforward early return in a place where we already had an assertion.
  • String changes made/needed: none
  • Is Android affected?: yes
Attached file (secure)
Attachment #9503213 - Flags: approval-mozilla-esr115?

firefox-esr115 Uplift Approval Request

  • User impact if declined: Potential security exploit.
  • Code covered by automated testing: no
  • Fix verified in Nightly: no
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing: not applicable
  • Risk associated with taking this patch: low
  • Explanation of risk level: Straightforward early return in a place where we already had an assertion.
  • String changes made/needed: none
  • Is Android affected?: yes
Attachment #9503211 - Flags: approval-mozilla-esr140? → approval-mozilla-esr140+
Attachment #9503212 - Flags: approval-mozilla-esr128? → approval-mozilla-esr128+
Attachment #9503213 - Flags: approval-mozilla-esr115? → approval-mozilla-esr115+
Whiteboard: [adv-main142+r][adv-esr140.2+r][adv-esr128.14+r][adv-esr115.27+r]
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: