crypto/tls: panic when processing partial post-handshake message in QUICConn.HandleData #62266
Comments
|
Change https://go.dev/cl/522595 mentions this issue: |
cagedmantis
added
the
NeedsFix
|
@gopherbot please backport to 1.21. This is a security vulnerability. |
|
Backport issue(s) opened: #62290 (for 1.21). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
|
Change https://go.dev/cl/523039 mentions this issue: |
neild
removed
the
NeedsFix
dmitshur
added
the
NeedsFix
…post-handshake messages The check for fragmentary post-handshake messages in QUICConn.HandleData was reversed, resulting in a potential panic when HandleData receives a partial message. In addition, HandleData wasn't checking the size of buffered post-handshake messages. Produce an error when a post-handshake message is larger than maxHandshake. TestQUICConnectionState was using an onHandleCryptoData hook in runTestQUICConnection that was never being called. (I think it was inadvertently removed at some point while the CL was in review.) Fix this test while making the hook more general. For #62266 Fixes #62290 Change-Id: I210b70634e50beb456ab3977eb11272b8724c241 Reviewed-on: https://go-review.googlesource.com/c/go/+/522595 Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Marten Seemann <martenseemann@gmail.com> Reviewed-by: Roland Shoemaker <roland@golang.org> (cherry picked from commit e92c0f8) Reviewed-on: https://go-review.googlesource.com/c/go/+/523039 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
Suggested release note:
|
Once the TLS handshake completes, QUICConn.HandleData buffers data and passes it to
handlePostHandshakeMessageevery time the buffer contains a complete message. The size check is wrong, however, so it can pass along a partial message, triggering a panic whenhandlePostHandshakeMessagetries to read the remainder of the message.In addition,
HandleDatadoesn't limit the amount of data it can buffer. It should reject messages larger thanmaxHandshake.Thanks to @marten-seemann for reporting this issue.
Normally, we'd consider this a PRIVATE track vulnerability, but this is a very new API and the only known user (quic-go) has already released a workaround in a patch release, so we're calling it PUBLIC track.
The panic due to partial messages is CVE-2023-39321.
The lack of a limit on buffered post-handshake data is CVE-2023-39322.
The text was updated successfully, but these errors were encountered: