1995686 - (CVE-2025-13020) Call to SendCaptureEnded looks suspicious

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect, P2)

Description

[Andreas Pehrson [:pehrsons] (PTO; back in Aug)]

I see no crash reports so unlikely to be hit in the wild, but in CallbackHelper::OnCaptureEnded there's a Dispatch to the PBackground event target with no lifetime guarantee for the passed variables.

Static analysis doesn't catch this because this is a CallbackHelper* which isn't ref-counted.

CamerasParent, which owns the CallbackHelpers, has NS_INLINE_DECL_THREADSAFE_REFCOUNTING_WITH_DELETE_ON_EVENT_TARGET(CamerasParent, mPBackgroundEventTarget) which is also the thread we are dispatching to. The CallbackHelpers have a shorter lifetime though, and could be deleted after the offending Dispatch but before its runnable has run.

To take advantage of this, an attacker would have to be able to trigger a permanent error in the screen/window capture backend. If they can do that they probably already control the machine, so exploit risk seems low.

Comment 1

[Andreas Pehrson [:pehrsons] (PTO; back in Aug)]

Attachment: (secure)

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/48f8a74041be
https://hg.mozilla.org/integration/autoland/rev/426d0bb3c451
Pass copies to SendCaptureEnded. r=jib,grulja

Comment 3

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/426d0bb3c451

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox145 to wontfix.

For more information, please visit BugBot documentation.

Comment 5

[Pascal Chevrel (relman team) -> :pascalc]

Do we want to uplift it to 145 and ESR140?

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

While the exploit risk seems low, the patch seems safe enough to take, so on balance I'd say yes.

Comment 7

[Pascal Chevrel (relman team) -> :pascalc]

Could you fill in the uplift request and nominate for beta and esr140? Thanks

Comment 8

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Comment on attachment 9521582 [details]
(secure)

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Low risk of parent process exploit per comment 0
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce: Crash not reproducible
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Adds a refcount
• String changes made/needed:
• Is Android affected?: Yes

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Low risk of parent process exploit per comment 0
• User impact if declined: See above
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Adds a refcount

Comment 9

[Pascal Chevrel (relman team) -> :pascalc]

The patch conflicts with the beta and esr140 branches, we'll need separate patches to uplift.

Comment 10

[Ryan VanderMeulen (PTO, back July 27)]

Comment on attachment 9521582 [details]
(secure)

Approved for 145.0b9 and 140.5esr.

Comment 11

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/d9229c9e4f84
https://hg.mozilla.org/releases/mozilla-beta/rev/86b0acb1447f

Comment 12

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/a926f18ecc2d

Comment 13

[Tom Schuster]

Attachment: advisory.txt