NTLM credentials not-checked for proxy connection reuse
libcurl reuses NTLM-authenticated proxy connections without properly making sure that the connection was authenticated with the same credentials as set for this transfer. libcurl maintains a pool of connections after a transfer has completed. The pool of connections is then gone through when a new transfer is requested and if there is a live connection available that can be reused, it is preferred instead of creating a new one. Since NTLM-based authentication is *connection oriented* instead of *request oriented* as other HTTP based authentication, it is important that only connections that have been authenticated with the correct username + password are reused. This was done properly for server connections already, but libcurl failed to do it properly for proxy connections using NTLM. A libcurl application can easily switch user credentials used for a proxy connection between two requests, and that subsequent transfer then MUST make libcurl use another connection. libcurl previously failed to do so. The effects of this flaw, is that the application could be reusing a proxy connection using the previously used credentials and thus it could be given to or prevented access from resources that it was not intended to. This problem is similar to [CVE-2014-0015](https://curl.se/docs/CVE-2014-0015.html), which was for direct server connections while this is for proxy connections.
02 / AFFECTED SOFTWARE
Affected packages
130 explicit affected versions
77 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
The ConnectionExists function in lib/url.c in libcurl before 7.47.0 does not properly re-use NTLM-authenticated proxy connections, which might allow remote attackers to authenticate as other users via a request, a similar issue to CVE-2014-0015.
libcurl reuses NTLM-authenticated proxy connections without properly making sure that the connection was authenticated with the same credentials as set for this transfer. libcurl maintains a pool of connections after a transfer has completed. The pool of connections is then gone through when a new transfer is requested and if there is a live connection available that can be reused, it is preferred instead of creating a new one. Since NTLM-based authentication is *connection oriented* instead of *request oriented* as other HTTP based authentication, it is important that only connections that have been authenticated with the correct username + password are reused. This was done properly for server connections already, but libcurl failed to do it properly for proxy connections using NTLM. A libcurl application can easily switch user credentials used for a proxy connection between two requests, and that subsequent transfer then MUST make libcurl use another connection. libcurl previously failed to do so. The effects of this flaw, is that the application could be reusing a proxy connection using the previously used credentials and thus it could be given to or prevented access from resources that it was not intended to. This problem is similar to [CVE-2014-0015](https://curl.se/docs/CVE-2014-0015.html), which was for direct server connections while this is for proxy connections.
05 / REFERENCES
Further evidence
- http://curl.haxx.se/docs/adv_20160127A.html
- http://lists.apple.com/archives/security-announce/2016/Sep/msg00006.html
- http://lists.fedoraproject.org/pipermail/package-announce/2016-February/176546.html
- http://lists.fedoraproject.org/pipermail/package-announce/2016-February/177342.html
- http://lists.fedoraproject.org/pipermail/package-announce/2016-February/177383.html
- http://lists.fedoraproject.org/pipermail/package-announce/2016-January/176413.html
- http://lists.opensuse.org/opensuse-updates/2016-02/msg00031.html
- http://lists.opensuse.org/opensuse-updates/2016-02/msg00044.html
- http://lists.opensuse.org/opensuse-updates/2016-02/msg00047.html
- http://packetstormsecurity.com/files/135695/Slackware-Security-Advisory-curl-Updates.html
- http://www.debian.org/security/2016/dsa-3455
- http://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html
- http://www.securityfocus.com/bid/82307
- http://www.securitytracker.com/id/1034882
- http://www.slackware.com/security/viewer.php?l=slackware-security&y=2016&m=slackware-security.519965
- http://www.ubuntu.com/usn/USN-2882-1
- https://security.gentoo.org/glsa/201701-47
- https://support.apple.com/HT207170