1855550 - (CVE-2023-5217) Chrome libvpx 0day

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Frederik Braun [:freddy]]

Chrome is affected by a 0day bug exploiting a vulnerability in libvpx, which is exposed through the WebCodec API.

We do not support the API but use libvpx elsewhere (mostly WebRTC) and should therefore investigate if this affects us and how fast we want to ship an update.

I'm rating this sec-critical, in case it is a Firefox 0day. Naturally, we want to rank this down if it isn't.

Comment 1

[Frederik Braun [:freddy]]

Attachment: asan stacktrace from Chrome unit test

Comment 2

[Frederik Braun [:freddy]]

Attachment: gtest diff

Comment 3

[Daniel Veditz [:dveditz]]

libvpx patch: https://chromium.googlesource.com/webm/libvpx/+/3fbd1dca6a4d2dad332a2110d646e4ffef36d590%5E%21/

webcodec patch (for comparison, not relevant to us):
https://chromium.googlesource.com/chromium/src/+/dd8d9efe3251e33dfe19fa0163626aa1b35946d0

Comment 4

[Daniel Veditz [:dveditz]]

We are not vulnerable to the Chrome exploit that's in the wild, which uses Web Codecs APIs that Firefox does not support (yet). But WebRTC can encode using VP8 and it's possible the bug could be triggered in Firefox by manipulating input streams to that.

Update: we later discovered that the MediaRecorder API also uses the vulnerable libvpx encoder, and we believe it could be used to trigger the vulnerability in Firefox.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Attachment: Bug 1855550 - VP8: disallow thread count changes.

Cherry-pick of upstream libvpx commit:
https://chromium.googlesource.com/webm/libvpx/+/3fbd1dca6a4d2dad332a2110d646e4ffef36d590

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Attachment: Bug 1855550 - Add test.

Comment 7

[Andrew McCreight [:mccr8]]

I'll mark this as csectype-bounds, as the description of this from Chrome's release notes is:
"[1486441] High CVE-2023-5217: Heap buffer overflow in vp8 encoding in libvpx. Reported by Clément Lecigne of Google's Threat Analysis Group on 2023-09-25"

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 9355423 [details]
Bug 1855550 - VP8: disallow thread count changes.

Security Approval Request

• How easily could an exploit be constructed based on the patch?: I assume not hard given the 0-day for chrome (if they figure out that MediaRecorder could be a vector, and MediaRecorder actually triggers it in an exploitable way)
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Yes
• Which older supported branches are affected by this flaw?: all
• 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?: trivial
• How likely is this patch to cause regressions; how much testing does it need?: Almost impossible to cause regressions
• Is Android affected?: Yes

Beta/Release Uplift Approval Request

• User impact if declined: active 0-day
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Trivial safe change
• String changes made/needed: none
• Is Android affected?: Yes

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9355423 [details]
Bug 1855550 - VP8: disallow thread count changes.

Per discussion in the incident Slack channel, we're going to move forward with shipping this fix ASAP. Approved for 118.0.1, 119.0b3, and 115.3.1esr.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c53f5ef77b62
VP8: disallow thread count changes. r=jesup

Comment 11

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/0862c284dac0

Comment 12

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/68e4c357d26c

Comment 13

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/749617c4473c

Comment 14

[Tyson Smith [:tsmith]]

Attachment: advisory.txt

Comment 15

[Tyson Smith [:tsmith]]

Attachment: advisory.txt

Comment 16

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/5241232a3292

Comment 17

[Tyson Smith [:tsmith]]

Attachment: advisory.txt

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/c53f5ef77b62

Comment 19

[Kai Engert (:KaiE:)]

(In reply to Daniel Veditz [:dveditz] from comment #4)

Update: we later discovered that the MediaRecorder API also uses the vulnerable libvpx encoder, and we believe it could be used to trigger the vulnerability in Firefox.

In Thunderbird, it seems difficult to reach the media recording code by viewing a web page, because there is no code to grant permission to the camera (said mkmelin), so video recording might be impossible.
However, we cannot rule out than an Add-on with higher privileges might trigger media recording, so it might be best to update Thunderbird, too.

Comment 20

[Daniel Veditz [:dveditz]]

You can use MediaRecorder with any MediaStream, including HTMLCanvasElement.captureStream()

Comment 21

[Kai Engert (:KaiE:)]

Daniel, thanks a lot for this clarification.
Then we should also do an urgent update for Thunderbird.

Comment 23

[Christian Holler (:decoder)]

Attachment: Testcase for Firefox with MediaRecorder

Comment 24

[Christian Holler (:decoder)]

Attachment: MediaRecorder Test ASan Log

Comment 25

[Daniel Veditz [:dveditz]]

The ASAN log from Christian's MediaRecorder testcase (attachment 9355617 [details]) are a beautiful match for the VideoRecorder testcase ASAN log from the Chrome bug.

The crashing threads are identical below mozilla::VP8TrackEncoder::Encode and media::VpxVideoEncoder::Encode, and the allocating threads are identical below mozilla::VP8TrackEncoder::Reconfigure and media::VpxVideoEncoder::ChangeOptions