1875701 - (CVE-2024-2613) firefox/neqo: unbounded mem alloc based on unsanitized network input

Status: RESOLVED FIXED

(Core :: Networking, defect, P2)

Description

[Max Inden]

Attachment: 0001-fix-transport-bound-ACK-range-count-in-ACK-frame.patch

Hi there,

This is Max Inden (https://github.com/mxinden).

I believe I found a security vulnerability affecting Firefox.

Summary

A malicious remote server can send a tampered QUIC ACK frame, causing a Firefox instance to attempt an effectively unbounded memory allocation and thus OOM.

Details

When decoding a QUIC ACK frame, Neqo will first read the ACK range count (nr) and then allocate a Vec with a capacity of the count (arr). It does not enforce an upper bound on the count. Thus an attacker can choose an arbitrarily large ACK range count and thus cause Neqo to attempt an effectively infinite memory allocation.

FRAME_TYPE_ACK | FRAME_TYPE_ACK_ECN => {
let la = dv(dec)?;
let ad = dv(dec)?;
let nr = dv(dec)?;
let fa = dv(dec)?;
let mut arr: Vec<AckRange> = Vec::with_capacity(nr as usize);

https://github.com/mozilla/neqo/blob/4de3279b8ac881ef4683a8331fc33c2917019562/neqo-transport/src/frame.rs#L410-L415

Next steps

I have attached a patch to this email. You can apply the patch onto latest Neqo main brach via:

git apply 0001-fix-transport-bound-ACK-range-count-in-ACK-frame.patch

I suggest looping in the Neqo maintainers.

• Martin Thomson <[e-mail]>
• Kershaw <[e-mail]>
• Lars Eggert <[e-mail]>

I am happy to open a GitHub advisory on the Neqo GitHub repository directly to ease the process.

Hope this is of some help!
Max

Comment 1

[Tom Ritter [:tjr]]

Moving to right component and adding cc's. Thanks!

Comment 2

[Kershaw Chang [:kershaw]]

Hi Max,

Thanks for filing this bug.
Could you open a github PR for the attached patch?

Thanks.

Comment 3

[Max Inden]

Could you open a github PR for the attached patch?

Yes, of course. Though wouldn't a GitHub advisory with a private pull request be more appropriate, given that this is security sensitive? I am fine either way.

Comment 4

[Martin Thomson [:mt:]]

Comment on attachment 9375675 [details] [diff] [review]
0001-fix-transport-bound-ACK-range-count-in-ACK-frame.patch

Review of attachment 9375675 [details] [diff] [review]:
-----------------------------------------------------------------

This looks like a fine fix.  I might go smaller, but we're still talking kB, not whatever it was before, which is good.

::: neqo-transport/src/frame.rs
@@ +59,5 @@
> +/// > the number of ACK blocks possible.
> +//
> +// Taken from
> +// [msquic](https://github.com/microsoft/msquic/blob/7d7a792d088abb80186a2fa20070ad82092e9736/src/core/frame.c#L257-L261).
> +const MAX_ACK_RANGE_COUNT: u64 = u16::MAX as u64;

Let's see.  An ACK range could be as little as two varints, each of which are one octet.  If the UDP payload is 64k, we really have at most 32k ranges.  That suggests that the cap could be 32k, not 64.

Comment 5

[Max Inden]

A smaller limit sounds good. I will make the adjustment.

Could you open a github PR for the attached patch?

Yes, of course. Though wouldn't a GitHub advisory with a private pull request be more appropriate, given that this is security sensitive? I am fine either way.

It is hard for me to judge what impact an OOM in a Neqo connection has on a running Firefox instance, thus the caution. I am fine with a public pull request. Can you please confirm that a public pull request is preferred, Kershaw? I am sorry for the back-and-forth.

Comment 6

[Kershaw Chang [:kershaw]]

(In reply to Max Inden from comment #5)

A smaller limit sounds good. I will make the adjustment.

Could you open a github PR for the attached patch?

Yes, of course. Though wouldn't a GitHub advisory with a private pull request be more appropriate, given that this is security sensitive? I am fine either way.

It is hard for me to judge what impact an OOM in a Neqo connection has on a running Firefox instance, thus the caution. I am fine with a public pull request. Can you please confirm that a public pull request is preferred, Kershaw? I am sorry for the back-and-forth.

Let's go with an advisory. Thanks!

Comment 7

[Max Inden]

I created an advisory and a private pull request with the above suggestions incorporated.

https://github.com/mozilla/neqo/security/advisories/GHSA-5m9j-vr32-g7j5

https://github.com/mozilla/neqo-ghsa-5m9j-vr32-g7j5/pull/1

Comment 8

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

We should get this fix into neqo; not high severity due to there being many ways to DOS a browser that can't be blocked. Thanks!

Comment 9

[Kershaw Chang [:kershaw]]

This bug is tracked here and will be fixed with a new lease of neqo.

Comment 10

[Kershaw Chang [:kershaw]]

Fixed by bug 1877942.
Thank you, Max!

Comment 11

[Daniel Veditz [:dveditz]]

Unfortunately DOS bugs are generally excluded from our bug bounty program

Comment 12

[Max Inden]

Unfortunately DOS bugs are generally excluded from our bug bounty program

Totally fine! Thank you for all the help getting this into Firefox.

Comment 13

[Tyson Smith [:tsmith]]

Attachment: advisory.txt