2048138 - audioipc2 StreamCreate/StreamInit mismatch permits parent audio callback buffer OOB read/write

Status: RESOLVED DUPLICATE of bug 2042033

(Core :: Audio/Video: cubeb, defect)

Description

[Atsushi Sada]

Attachment: patch.diff

A compromised content process can obtain a parent-created audioipc pipe via PContent::CreateAudioIPCConnection and send raw audioipc RPC messages. The server records callback input/output frame sizes from StreamCreate, but initializes the cubeb stream from later StreamInit parameters without requiring the two requests to match. A client can create a stream with large input/output frame sizes and initialize it with smaller valid formats. On input callbacks, data_cb_c treats the smaller cubeb input buffer as a larger slice and copies parent-side out-of-bounds bytes into the shared memory returned to the child. On output callbacks, it treats the smaller cubeb output buffer as a larger mutable slice and copies child-controlled shared-memory bytes past the end of the parent audio callback buffer. The patch validates StreamCreate parameters and rejects StreamInit requests whose input/output frame sizes do not match the created stream.

Comment 1

[Daniel Veditz [:dveditz]]

Do you have a testcase that demonstrates the bug?

Comment 2

[Atsushi Sada]

Yes. I attached testcase-audioipc2-callback-oob.patch.

It adds two ASan-oriented Rust tests under third_party/rust/audioipc2-server/src/server.rs:

• stream_create_init_mismatch_input_callback_oob_read
• stream_create_init_mismatch_output_callback_oob_write

The tests call process_stream_create() with a large frame size, then invoke data_cb_c with the smaller parent callback buffer that a mismatched StreamInit would cause cubeb to use. This models the raw audioipc RPC state a compromised content process can create; the normal audioipc2-client wrapper does not create the mismatch because it reuses the same params for both messages.

Run on the vulnerable revision

cd mozilla-central
hg update -r 67c09b0f6c1f
patch -p1 < /path/to/testcase-audioipc2-callback-oob.patch

export RUSTFLAGS="-Zsanitizer=address -Cforce-frame-pointers=yes"

ASAN_OPTIONS=detect_leaks=0:abort_on_error=1 \
cargo +nightly test -Zbuild-std --target x86_64-unknown-linux-gnu \
  --manifest-path third_party/rust/audioipc2-server/Cargo.toml \
  stream_create_init_mismatch_input_callback_oob_read -- --nocapture

ASAN_OPTIONS=detect_leaks=0:abort_on_error=1 \
cargo +nightly test -Zbuild-std --target x86_64-unknown-linux-gnu \
  --manifest-path third_party/rust/audioipc2-server/Cargo.toml \
  stream_create_init_mismatch_output_callback_oob_write -- --nocapture

Expected result: the first test reports an ASan heap-buffer-overflow read from the parent input callback buffer; the second reports an ASan heap-buffer-overflow write to the parent output callback buffer.

Comment 3

[Atsushi Sada]

Attachment: testcase-audioipc2-callback-oob.patch

Comment 4

[Simon Friedberger [:simonf]]

The rating assigned by our bug rating tool (currently under development) is:

Rating: sec-high

Explanation: A compromised content process can exploit a mismatch between audioipc2 StreamCreate and StreamInit parameters to cause OOB memory access in the parent (privileged) audio process. StreamCreate stores input/output frame sizes in ServerStreamCallbacks and allocates shm based on them, but StreamInit initializes the cubeb stream with potentially different (smaller) params without verifying the frame sizes match. In data_cb_c, the callback uses the StreamCreate-derived frame sizes to construct slices over the actual (smaller) audio buffers, causing: (1) OOB read — parent memory beyond the actual input buffer is read and exfiltrated to the child via shared memory; (2) OOB write — attacker-controlled shm bytes are written past the end of the parent's output callback buffer. This is a memory safety issue (OOB read/write) in the parent process exploitable from a compromised content process, constituting a sandbox escape. Rated sec-high per the 'Memory Safety issues' and 'Sandbox escapes' criteria.

Please ni? me if you disagree with this rating.