libcurl can wrongly send HTTP credentials when re-using
connections.
libcurl allows applications to set credentials for the
upcoming transfer with HTTP Basic authentication, like
with CURLOPT_USERPWD for example. Name and password.
Just like all other libcurl options the credentials
are sticky and are kept associated with the "handle"
until something is made to change the situation.
Further, libcurl offers a curl_easy_reset() function
that resets a handle back to its pristine state in
terms of all settable options. A reset is of course
also supposed to clear the credentials. A reset is
typically used to clear up the handle and prepare
it for a new, possibly unrelated, transfer.
Within such a handle, libcurl can also store a
set of previous connections in case a second transfer
is requested to a host name for which an existing
connection is already kept alive.
With this flaw present, using the handle even
after a reset would make libcurl accidentally use
those credentials in a subsequent request if done
to the same host name and connection as was
previously accessed.
An example case would be first requesting a password
protected resource from one section of a web site, and
then do a second request of a public resource from a
completely different part of the site without
authentication. This flaw would then inadvertently
leak the credentials in the second request.
libcurl can get tricked by a malicious SMB server to
send off data it did not intend to.
In libcurl's state machine function handling the SMB
protocol (smb_request_state()), two length and offset
values are extracted from data that has arrived over
the network, and those values are subsequently used
to figure out what data range to send back.
The values are used and trusted without boundary
checks and are just assumed to be valid. This allows
carefully handcrafted packages to trick libcurl
into responding and sending off data that was not
intended. Or just crash if the values cause libcurl
to access invalid memory.