Skip to content

fix(deps): update module github.com/quic-go/quic-go to v0.49.1 [security] #175

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

fix(deps): update module github.com/quic-go/quic-go to v0.49.1 [security] #175

wants to merge 1 commit into from

Conversation

@renovate
Copy link
Contributor

@renovate renovate bot commented Aug 6, 2024 •
edited
Loading

This PR contains the following updates:

Package Change Age Confidence
github.com/quic-go/quic-go v0.35.1 -> v0.49.1 age confidence

GitHub Vulnerability Alerts

CVE-2023-49295

An attacker can cause its peer to run out of memory sending a large number of PATH_CHALLENGE frames. The receiver is supposed to respond to each PATH_CHALLENGE frame with a PATH_RESPONSE frame. The attacker can prevent the receiver from sending out (the vast majority of) these PATH_RESPONSE frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate.

I published a more detailed description of the attack and its mitigation in this blog post: https://seemann.io/posts/2023-12-18-exploiting-quics-path-validation/

There's no way to mitigate this attack, please update quic-go to a version that contains the fix.

CVE-2024-22189

An attacker can cause its peer to run out of memory by sending a large number of NEW_CONNECTION_ID frames that retire old connection IDs. The receiver is supposed to respond to each retirement frame with a RETIRE_CONNECTION_ID frame. The attacker can prevent the receiver from sending out (the vast majority of) these RETIRE_CONNECTION_ID frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate.

I published a more detailed description of the attack and its mitigation in this blog post: https://seemann.io/posts/2024-03-19-exploiting-quics-connection-id-management/.
I also presented this attack in the IETF QUIC working group session at IETF 119: https://youtu.be/JqXtYcZAtIA?si=nJ31QKLBSTRXY35U&t=3683

There's no way to mitigate this attack, please update quic-go to a version that contains the fix.

CVE-2024-53259

Impact

An off-path attacker can inject an ICMP Packet Too Large packet. Since affected quic-go versions used IP_PMTUDISC_DO, the kernel would then return a "message too large" error on sendmsg, i.e. when quic-go attempts to send a packet that exceeds the MTU claimed in that ICMP packet.

By setting this value to smaller than 1200 bytes (the minimum MTU for QUIC), the attacker can disrupt a QUIC connection. Crucially, this can be done after completion of the handshake, thereby circumventing any TCP fallback that might be implemented on the application layer (for example, many browsers fall back to HTTP over TCP if they're unable to establish a QUIC connection).

As far as I understand, the kernel tracks the MTU per 4-tuple, so the attacker needs to at least know the client's IP and port tuple to mount an attack (assuming that it knows the server's IP and port).

Patches

The fix is easy: Use IP_PMTUDISC_PROBE instead of IP_PMTUDISC_DO. This socket option only sets the DF bit, but disables the kernel's MTU tracking.

Has the problem been patched? What versions should users upgrade to?

Fixed in https://github.com/quic-go/quic-go/pull/4729
Released in https://github.com/quic-go/quic-go/releases/tag/v0.48.2

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

Use iptables to drop ICMP Unreachable packets.

References

Are there any links users can visit to find out more?

This bug was discovered while doing research for my new IETF draft on IP fragmentation: https://datatracker.ietf.org/doc/draft-seemann-tsvwg-udp-fragmentation/

CVE-2025-59530

Summary

A misbehaving or malicious server can trigger an assertion in a quic-go client (and crash the process) by sending a premature HANDSHAKE_DONE frame during the handshake.

Impact

A misbehaving or malicious server can cause a denial-of-service (DoS) attack on the quic-go client by triggering an assertion failure, leading to a process crash. This requires no authentication and can be exploited during the handshake phase. Observed in the wild with certain server implementations (e.g. Solana's Firedancer QUIC).

Affected Versions

  • All versions prior to v0.49.1 (for the 0.49 branch)
  • Versions v0.50.0 to v0.54.0 (inclusive)
  • Fixed in v0.49.1, v0.54.1, and v0.55.0 onward

Users are recommended to upgrade to the latest patched version in their respective maintenance branch or to v0.55.0 or later.

Details

For a regular 1-RTT handshake, QUIC uses three sets of keys to encrypt / decrypt QUIC packets:

  • Initial keys (derived from a static key and the connection ID)
  • Handshake keys (derived from the client's and server's key shares in the TLS handshake)
  • 1-RTT keys (derived when the TLS handshake finishes)

On the client side, Initial keys are discarded when the first Handshake packet is sent. Handshake keys are discarded when the server's HANDSHAKE_DONE frame is received, as specified in section 4.9.2 of RFC 9001. Crucially, Initial keys are always dropped before Handshake keys in a standard handshake.

Due to packet reordering, it is possible to receive a packet with a higher encryption level before the key for that encryption level has been derived. For example, the server's Handshake packets (containing, among others, the TLS certificate) might arrive before the server's Initial packet (which contains the TLS ServerHello). In that case, the client queues the Handshake packets and decrypts them as soon as it has processed the ServerHello and derived Handshake keys.

After completion of the handshake, Initial and Handshake packets are not needed anymore and will be dropped. quic-go implements an assertion that no packets are queued after completion of the handshake.

A misbehaving or malicious server can trigger this assertion, and thereby cause a panic, by sending a HANDSHAKE_DONE frame before actually completing the handshake. In that case, Handshake keys would be dropped before Initial keys.

This can only happen if the server implementation is misbehaving: the server can only complete the handshake after receiving the client's TLS Finished message (which is sent in Handshake packets).

The Fix

quic-go needs to be able to handle misbehaving server implementations, including those that prematurely send a HANDSHAKE_DONE frame. We now discard Initial keys when receiving a HANDSHAKE_DONE frame, thereby correctly handling premature HANDSHAKE_DONE frames. The fix was implemented in https://github.com/quic-go/quic-go/pull/5354.

Release Notes

quic-go/quic-go (github.com/quic-go/quic-go)

v0.49.1

Compare Source

v0.49.0

Compare Source

In this release, we added support for HTTP client traces. We also fixed a large number of bugs that could lead to connection stalls, deadlocks and memory leaks. See the "Major Fixes" section for more details.

New Features

  • http3: add support for client traces net/http/httptrace.ClientTrace: #​4749. Thanks to @​lRoccoon for the contribution!

Major Fixes

  • fix accounting for lost RESET_STREAM frames in the stream, leading to potential connection stalls / deadlocks: #​4804. Thanks to @​Wondertan for reporting and testing the fix!
  • fix memory leak when the connection ID is rotated when the CONNECTION_CLOSE packet is sent: #​4852. Thanks to @​MarcoPolo for debugging this issue and contributing a fix!
  • http3: fix QUIC connection re-dialing logic: #​4854, #​4875, #​4879
  • trigger sending of a new packet when a MAX_DATA frame (connection-level flow control update) is queued: #​4844
  • Transport.Close was reworked: calls to Transport.Dial are now canceled, and return the newly introduced ErrTransportClosed, as do calls to Transport.Listen: #​4883

Enhancements

  • trace dropping of packets by the Transport when no server is set: #​4789
  • trace dropping of packets that the Transport doesn't send a stateless for: #​4826
  • drain received packets when the connection is closed: #​4773
  • add Prometheus metrics for sent and received packets: #​4910
  • reduce calls to time.Now all over the code base: #​4731, #​4885, #​4886, #​4906
  • packetize DATA_BLOCKED frames in the same QUIC packet that caused us to block on connection-level flow control: #​4845
  • packetize STREAM_DATA_BLOCKED frames in the same QUIC packed that caused us to block on stream-level flow control: #​4801
  • we now don't enforce that only one Transport listens on any given net.PacketConn: #​4851

Other Fixes

  • drain the server's connection accept queue before returning ErrClosed from Accept: #​4846. Thanks to @​sukunrt for discovering this bug and providing very helpful reviews!
  • preserve the error returned from SendStream.Write if it is closed after is canceled: #​4882
  • fix race condition on concurrent calls to Transport.Dial and Transport.Close: #​4904
  • qlog: fix logging of packet_in_flight on the metrics_updated event: #​4895
  • fix errors.Is error comparisons: #​4824, #​4825, #​4877
  • http3: fix race condition on concurrent calls to http.Response.Body.Close: #​4798. Thanks to @​RPRX for the contribution!
  • flowcontrol: reset the connection send window on 0-RTT rejection: #​4764
  • wait for connection to shut down when the Dial context is cancelled: #​4872
  • http3: the http.Request.Body is now properly closed on all code paths that return a non-nil error: #​4874
  • NEW_CONNECTION_ID frames are now rejected when zero-length connection IDs are used, as required by the RFC: #​4878
  • the stream ID of STREAM_DATA_BLOCKED frames is now validated, as required by the RFC: #​4836
  • fix ECN markings of packets sent in GSO batches when the marking changes: #​4835
  • the AEAD used to calculate the Retry Integrity Tag is now created lazily, avoiding a panic on initialization when using Go 1.24 FIPS-only mode: #​4916
  • use a 24h maximum token age as default value for Transport.MaxTokenAge: #​4763

Behind the Scenes

In the v0.48.0 release, we started migrating our test suite away from Ginkgo (tracking issue: #​3652). This is an absolutely massive endeavor. Before we started, the number of LOC of Ginkgo tests was more than 41,000.

In this release, we're bringing this number down to less than 8,500 LOC: #​4736, #​4746, #​4775, #​4783, #​4788, #​4790, #​4795, #​4796, #​4797, #​4799, #​4814, #​4816, #​4817, #​4823, #​4837, #​4842, #​4847, #​4848, #​4849, #​4853, #​4857, #​4860, #​4861, #​4862, #​4863, #​4864, #​4865, #​4869, #​4876, #​4881, #​4907.

There's still a lot of work ahead, but we'll hopefully be able to finish this item in the next couple of months.

Changelog

New Contributors

Full Changelog: quic-go/quic-go@v0.48.2...v0.49.0

v0.48.2

Compare Source

This patch release contains fixes for three bugs, including a patch for CVE-2024-53259 (details).

Changelog

Full Changelog: quic-go/quic-go@v0.48.1...v0.48.2

v0.48.1

Compare Source

This patch releases fixes a panic in the shutdown logic of the http3.Server that was introduced in v0.48.0. Thanks to @​WeidiDeng for the fix!

Changelog

Full Changelog: quic-go/quic-go@v0.48.0...v0.48.1

v0.48.0

Compare Source

New Features

The http3.Server now supports graceful shutdown: calling Shutdown stops the server from accepting new connections, and new HTTP requests on existing connections. It continues serving existing connections until all active requests have completed (or the context is canceled).

On the wire, graceful shutdown is signaled by sending a GOAWAY frame. This tells the client that the server will not accept any new requests. Clients are expected to finish existing requests and then close the QUIC connection.

Client-side support for graceful shutdown is not implemented yet (see #​153).

Breaking Changes

  • The HTTP/3 client API was made more consistent with the Go standard library's HTTP/1 and HTTP/2 naming: #​4693
  • The deprecated qlog.DefaultTracer function was removed: #​4697
  • The deprecated http3.Server.SetQuicHeader method and http3.ListenAndServe were removed: #​4698
  • http3.Server.Close now closes immediately all QUIC connections: #​4689

Note that all connection passed to http3.Server.ServeQUICConn need to be closed by the caller, before calling http3.Server.Close.

Notable Fixes

  • Canceling a stream after connection termination now doesn't change the error returned from Stream.Write and Stream.Read (thanks to @​sukunrt for the fix): #​4673
  • HTTP/3 Capsule Parsing logic didn't work for capsules that weren't read with a single Read call: #​4683

Behind The Scenes

We've started migrating our test suite away from Ginkgo (tracking issue: #​3652), and towards a more idiomatic approach to testing Go code (using require). This is a massive endeavour, as our test suite is around 41k LOC.

In this release, a large number of Go packages were translated: #​4640, #​4641, #​4642, #​4643, #​4649, #​4650, #​4652, #​4662, #​4670, #​4671, #​4675, #​4667, #​4676, #​4680, #​4681.

In the upcoming release(s), we will continue this work.

Changelog

Full Changelog: quic-go/quic-go@v0.47.0...v0.48.0

v0.47.0

Compare Source

New Features

This release adds support for HTTP/3 Trailers, for both the server and the client side (#​4581, #​4630, #​4656, #​4639). Trailers work exactly the same way as for HTTP/1.1 and HTTP/2.

A big thank you to @​sudorandom for contributing this feature!

Fixes

  • idle timeout calculation when the peer sends a max_idle_timeout of 0 (or omits the transport parameter): #​4666
  • fix handling of corrupted coalesced 1-RTT packets: #​4663
  • qpack: don't reject literal field lines with name references if N bit is set to 1: quic-go/qpack#52
  • http3: correctly set the http.Response.ContentLength on responses that don't set the Content-Length header: #​4645
  • http3: reject connection-specific header fields (Connection, Keep-Alive, Proxy-Connection, Transfer-Encoding, Upgrade and TE != "trailers"): #​4646, #​4655

Breaking Changes

  • quic.VersionNumber and logging.VersionNumber were removed: #​4627

Heads-Up

@​sukunrt recently discovered and reported a race condition in the new time.Timer stopping logic introduced in Go 1.23. This manifests as a connection deadlock in quic-go. See #​4659 and golang/go#69312 for more details. The new behavior is enabled when compiling with Go 1.23.x, and when the Go version in go.mod is set to Go 1.23.x.

Until this issue is fixed, it is recommended to either use Go 1.22.x, or to use GODEBUG="asynctimerchan=1" when compiling quic-go.

Update (Oct 1st 2024)

The Go project backported the fix (golang/go#69333) to the 1.23 branch, and released it in Go 1.23.2. This resolves above-mentioned issue. quic-go can now be built with Go 1.23.2, without the need to set any GODEBUG flags.

Changelog

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
Copy link
Contributor Author

renovate bot commented Aug 6, 2024 •
edited
Loading

ℹ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

  • 4 additional dependencies were updated
  • The go directive was updated for compatibility reasons

Details:

Package Change
go 1.20 -> 1.22
golang.org/x/net v0.11.0 -> v0.28.0
golang.org/x/crypto v0.10.0 -> v0.26.0
golang.org/x/exp v0.0.0-20230522175609-2e198f4a06a1 -> v0.0.0-20240506185415-9bf2ced13842
golang.org/x/mod v0.11.0 -> v0.18.0

@renovate renovate bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 4bc014f to 196055b Compare September 11, 2024 17:29
@renovate renovate bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 196055b to 17421a7 Compare November 17, 2024 15:36
@renovate renovate bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 17421a7 to 521838f Compare December 2, 2024 19:52
@renovate renovate bot changed the title fix(deps): update module github.com/quic-go/quic-go to v0.42.0 [security] fix(deps): update module github.com/quic-go/quic-go to v0.48.2 [security] Dec 2, 2024
@renovate renovate bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 521838f to daf97a2 Compare December 22, 2024 18:48
@renovate renovate bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from daf97a2 to 570e01f Compare March 3, 2025 13:17
@renovate renovate bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 570e01f to e55126f Compare March 11, 2025 09:25
@renovate renovate bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from e55126f to 599645d Compare April 8, 2025 16:06
@socket-security
Copy link

socket-security bot commented Apr 8, 2025 •
edited
Loading

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security		 Vulnerability Quality Maintenance License
Updatedgithub.com/​quic-go/​quic-go@​v0.35.1 ⏵ v0.49.174 +1100 +22100100100
Updatedgolang.org/​x/​net@​v0.11.0 ⏵ v0.28.075 +198 +17100100100

View full report

@renovate renovate bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 599645d to 845f197 Compare May 7, 2025 10:49
@renovate renovate bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 845f197 to 3c0cb8b Compare August 10, 2025 14:35
@renovate renovate bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 3c0cb8b to a1b8d05 Compare October 9, 2025 15:33
@renovate renovate bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from a1b8d05 to 85b6589 Compare October 10, 2025 20:50
@renovate renovate bot changed the title fix(deps): update module github.com/quic-go/quic-go to v0.48.2 [security] fix(deps): update module github.com/quic-go/quic-go to v0.49.1 [security] Oct 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants