]> git.ipfire.org Git - thirdparty/curl.git/commit
sendf: change Curl_read_plain to wrap Curl_recv_plain
authorJay Satiro <raysatiro@yahoo.com>
Mon, 14 Nov 2022 08:30:30 +0000 (03:30 -0500)
committerJay Satiro <raysatiro@yahoo.com>
Fri, 18 Nov 2022 08:04:13 +0000 (03:04 -0500)
commit12e1def51a75392df62e65490416007d7e68dab9
tree842c59a11b447d53f3e2d810d61e77bbe5d76fa2
parent856b133f5d62475d4cc12624c4cccb4170134712
sendf: change Curl_read_plain to wrap Curl_recv_plain

Prior to this change Curl_read_plain would attempt to read the
socket directly. On Windows that's a problem because recv data may be
cached by libcurl and that data is only drained using Curl_recv_plain.

Rather than rewrite Curl_read_plain to handle cached recv data, I
changed it to wrap Curl_recv_plain, in much the same way that
Curl_write_plain already wraps Curl_send_plain.

Curl_read_plain -> Curl_recv_plain
Curl_write_plain -> Curl_send_plain

This fixes a bug in the schannel backend where decryption of arbitrary
TLS records fails because cached recv data is never drained. We send
data (TLS records formed by Schannel) using Curl_write_plain, which
calls Curl_send_plain, and that may do a recv-before-send
("pre-receive") to cache received data. The code calls Curl_read_plain
to read data (TLS records from the server), which prior to this change
did not call Curl_recv_plain and therefore cached recv data wasn't
retrieved, resulting in malformed TLS records and decryption failure
(SEC_E_DECRYPT_FAILURE).

The bug has only been observed during Schannel TLS 1.3 handshakes. Refer
to the issue and PR for more information.

Ref: https://github.com/curl/curl/issues/9431#issuecomment-1312420361

Assisted-by: Joel Depooter
Reported-by: Egor Pugin
Fixes https://github.com/curl/curl/issues/9431
Closes https://github.com/curl/curl/pull/9904
lib/krb5.c
lib/sendf.c
lib/sendf.h
lib/socks.c
lib/vtls/schannel.c