Follow up fix to commit 62bd217464 to cater for servers that don't
respond with a 250 in their EHLO responses. Additionally updated the
SMTP tests to respond with a 250 response code as per RFC5321.
Fixed the SASL capability detection to include the space character
before the authentication mechanism list. Otherwise a capability such
as SASLSOMETHING would be interpreted as enabling SASL and potentially
trying to identify SOMETHING as a mechanism.
Previously if a problem was found with one of the server's certificates,
we'd log an OSStatus for the end user to look up. Now we explain what
was wrong with the site's certificate chain. Also un-did part of the
previous commit where the code wouldn't catch errSSLServerAuthCompleted
if built under Leopard.
Fixed a small issue where smtp_endofresp() would look for capabilities
in the description part of a failure response. In theory a server
shouldn't respond with SIZE or AUTH in an EHLO command's failure
response but if it did then capabilities would be unnecessarily set
before eventually failing.
Renamed the authstate1 and authstate2 variables in imap_authenticate()
as the old name was a left over from when there was only one state
variable which was named due to a clash with the state() function.
Additionally this provides consistency with the smtp module.
Running tests\libtest\libntlmconnect.exe reveals a 1 byte (!) leak in
./lib/curl_ntlm_msgs.c:
perl ..\memanalyze.pl c:memdebug.curl
Leak detected: memory still allocated: 1 bytes
At 9771e8, there's 1 bytes.
allocated by curl_ntlm_msgs.c:399
Snippet from curl_ntlm_msgs.c:
/* setup ntlm identity's domain and length */
dup_domain.tchar_ptr = malloc(sizeof(TCHAR) * (domlen + 1));
(my domlen == 0).
'dup_domain.tbyte_ptr' looks to be freed in Curl_ntlm_sspi_cleanup() via
'ntlm->identity.Domain'. But I see no freeing of 'dup_domain.tchar_ptr'.
This bug report properly identified that when doing SMTP and aborting
the transfer with a callback, it must be considered aborted prematurely
by the code to avoid QUIT etc to be attempted as that would cause a
hang.
The new test case 1507 verifies this behavior.
Reported by: Patricia Muscalu
Bug: http://curl.haxx.se/bug/view.cgi?id=1184
It turns out that Leopard (OS X 10.5) doesn't have constants for the ECDH
ciphers in its headers, so the cases for them have been taken out of the
build when building under Leopard. Also added a standard function for
getting a string description of a SecCertificateRef.
Changed the SMTP_AUTH_PASSWD state constant to SMTP_AUTH_LOGIN_PASSWD to
better describe the state as the second part of an AUTH LOGIN command,
as well as for consistency with the imap and pop3 modules.
Introduced detection of the SASL-IR capability, in order to add support
for sending the initial response with the AUTHENTICATE command, as per
RFC4959.
Updated the automatic response tag generation to follow the examples
given in RC3501, which list a 4 character string such as A001, A002,
etc.
As a unique identifier should be generated for each command the string
generation is based on the connection id and the incrementing command
id.
This is untested, but ought to be enough to still allow it
to work automatically when the entire curl source tree is
dropped into a full Android source tree.
VC6 is _very_ old and we provide working makefiles even for that
compiler. Users who build with the IDE never use that method and project
file anyway and it was just lingering in the root dir.
Added IDN and HTTP data compression as they were left out of the
document until now.
Added notes for qssl, schannel and Secure Transport supporting SSLv2,
Secure Transport supports NTLM, and axTLS does not support SSLv3.
There was also a typo; "AUTH TSL" should be "AUTH TLS".
When negotiating SASL DIGEST-MD5 authentication, the function
Curl_sasl_create_digest_md5_message() uses the data provided from the
server without doing the proper length checks and that data is then
appended to a local fixed-size buffer on the stack.
This vulnerability can be exploited by someone who is in control of a
server that a libcurl based program is accessing with POP3, SMTP or
IMAP. For applications that accept user provided URLs, it is also
thinkable that a malicious user would feed an application with a URL to
a server hosting code targetting this flaw.
Bug: http://curl.haxx.se/docs/adv_20130206.html
