Set Ready For Review
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +2 |
The fix & test look good to me, but I think the malicious server angle referenced by the commit message could use a bit more supporting analysis.
hang.Can you expand on this point? I'm not sure I see a way that a malicious server could deliver a triggering ECH config list payload. I agree it's worth fixing in either case, but I think the impact might be overstated (or I'm missing a detail).
AFAICT, there are ~2 primary methods an ECH config list is likely to arrive. 1. by way of a TLS hello retry request (HRR) providing retry configs 2. By DNS HTTPS-record SvcParams.
The first would be bounded by a uint16 length prefixed handshake message (`opaque<0..2^16-1>`), and the second would be bounded by "a 2-octet field containing the length of the SvcParamValue as an integer between 0 and 65535 in network byte order." (rfc9460)
A 65532 byte long ECHConfig would be 65536 bytes on the wire, plus another 2 for the header, like the 65538 payload from TestDecodeECHConfigListOverflow. Unless I'm mistaken I think that isn't something that could be delivered by a malicious server in practice.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Can you expand on this point? I'm not sure I see a way that a malicious server could deliver a triggering ECH config list payload. I agree it's worth fixing in either case, but I think the impact might be overstated (or I'm missing a detail).
AFAICT, there are ~2 primary methods an ECH config list is likely to arrive. 1. by way of a TLS hello retry request (HRR) providing retry configs 2. By DNS HTTPS-record SvcParams.
The first would be bounded by a uint16 length prefixed handshake message (`opaque<0..2^16-1>`), and the second would be bounded by "a 2-octet field containing the length of the SvcParamValue as an integer between 0 and 65535 in network byte order." (rfc9460)
A 65532 byte long ECHConfig would be 65536 bytes on the wire, plus another 2 for the header, like the 65538 payload from TestDecodeECHConfigListOverflow. Unless I'm mistaken I think that isn't something that could be delivered by a malicious server in practice.
Ah, indeed, thanks for pointing that out! Updated the commit message and the issue.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
The fix & test look good to me, but I think the malicious server angle referenced by the commit message could use a bit more supporting analysis.
Thanks for the review! After some discussion with the team, given that the overflow cannot really happen in realistic scenario, we're going to treat this as a security hardening rather than a vulnerability.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +2 |
Nicholas HusinThe fix & test look good to me, but I think the malicious server angle referenced by the commit message could use a bit more supporting analysis.
Thanks for the review! After some discussion with the team, given that the overflow cannot really happen in realistic scenario, we're going to treat this as a security hardening rather than a vulnerability.
SGTM! Thanks for fixing.
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
crypto/tls: avoid overflow in parseECHConfigList
When parsing an ECHConfigList, length fields were previously evaluated
as a uint16. This would cause an infinite loop to occur when parsing a
65532 bytes long ECHConfig with a declared outer length header of 0.
Triggering this condition requires a payload of at least 65538 bytes. As
ECHConfigList payloads are typically delivered via protocols that limit
them to 65535 bytes (DNS HTTPS records and TLS extensions), regular
clients are safe from this issue.
Thank you to Nguyễn Hoàng Hải (facebook...@gmail.com) for reporting
this issue.
Fixes #80513
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |