Bug 1260178

Summary: curl and libcurl truncates username/password in URL to 255 characters
Product: Red Hat Enterprise Linux 7 Reporter: Cesar Wong <cewong>
Component: curlAssignee: Kamil Dudka <kdudka>
Status: CLOSED ERRATA QA Contact: Stefan Dordevic <sdordevi>
Severity: unspecified Docs Contact: Lenka Špačková <lkuprova>
Priority: unspecified    
Version: 7.1CC: apeddire, cewong, kdudka, ovasik, redhat, santony, sdordevi
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: curl-7.29.0-30.el7 Doc Type: Bug Fix
Doc Text:
*libcurl* no longer truncates long user names and passwords The URL parser in the *libcurl* library previously did not support arbitrarily long user names and passwords. Consequently, user names and passwords longer than 255 characters were truncated. A series of upstream patches has been applied on the *libcurl* source code, and long user names and passwords in the URLs are now processed correctly by *libcurl*.
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-03 17:43:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1203710, 1289025, 1295829, 1313485    
Attachments:
Description Flags
backport of 28 (+5 trivial) upstream commits kdudka: review?

Description Cesar Wong 2015-09-04 16:21:42 UTC
Description of problem:

Invoking $ curl http://[username]:[password]@some.url/

where the length of username or password is greater than 255 characters, truncates the value to 255 characters.

Version-Release number of selected component (if applicable):
curl-7.29.0-19.el7.x86_64

How reproducible: Always


Steps to Reproduce:
1. # Generate a long password string
   $ PASSWORD=$(head -c 300 < /dev/zero | tr '\0' '\141')
2. # Invoke curl with the password and inspect the authorization header
   $ SENTPASSWORD=$(curl -v http://test:${PASSWORD}@redhat.com/ 2>&1 | grep "Authorization" | awk '{ print $4}' | base64 -di | cut -d: -f2)
3. # Test whether the sent password is the same as the original password
   $ if [ $PASSWORD = $SENTPASSWORD ]; then echo "Success"; fi

Actual results:
No success message is printed. The sent password is 255 characters, while the original password is 300 characters.

Expected results:
Success is printed. The original password and the password sent by curl are the same.

Additional info:
The same test succeeds in Fedora 22. The issue has been fixed in curl v7.33

Comment 3 Kamil Dudka 2015-09-07 17:25:58 UTC
Created attachment 1071073 [details]
backport of 28 (+5 trivial) upstream commits

I propose to pick the following 28 (+5 trivial) upstream commits:

> https://github.com/bagder/curl/commit/73aa9559 - url: Added support for parsing login options from the URL
> https://github.com/bagder/curl/commit/90c87f31 - url: Reworked URL parsing to allow overriding by CURLOPT_USERPWD
> https://github.com/bagder/curl/commit/0d49e408 - url: Re-factored set_userpass() and parse_url_userpass()
> https://github.com/bagder/curl/commit/bb20989a - url: Moved parsing of login details out of parse_url_login()
> https://github.com/bagder/curl/commit/49184c37 - url: Added bounds checking to parse_login_details()
> https://github.com/bagder/curl/commit/fddb7b44 - url: Added support for parsing login options from the CURLOPT_USERPWD
> https://github.com/bagder/curl/commit/d535c4a2 - url: Added overriding of URL login options from CURLOPT_USERPWD
> https://github.com/bagder/curl/commit/fe880475 - url: Fixed memory leak in setstropt_userpwd()
> https://github.com/bagder/curl/commit/e99c81a0 - url: Correction to scope of if statements when setting data
> https://github.com/bagder/curl/commit/bddf3d47 - url: Simplified setstropt_userpwd() following recent changes
> https://github.com/bagder/curl/commit/e8a9f794 - url: Tidy up of code and comments following recent changes
> https://github.com/bagder/curl/commit/702b0dd4 - url: Tidy up of setstropt_userpwd() parameters
> https://github.com/bagder/curl/commit/11332577 - url: Updated proxy URL parsing to use parse_login_details()
> https://github.com/bagder/curl/commit/416ecc15 - url: Fixed crash when no username or password supplied for proxy
> https://github.com/bagder/curl/commit/ddac43b3 - url: Fixed missing length check in parse_proxy()
> https://github.com/bagder/curl/commit/abca89aa - url: restore the functionality of 'curl -u :'
> https://github.com/bagder/curl/commit/83f0dae1 - url.c: fix parse_login_details() OOM handling
> https://github.com/bagder/curl/commit/cfc907e4 - url.c: fix parse_url_login() OOM handling
> https://github.com/bagder/curl/commit/53333a43 - url: use goto in create_conn() for exception handling
> https://github.com/bagder/curl/commit/11baffbf - url: allocate username, password, and options on the heap
> https://github.com/bagder/curl/commit/36585b53 - netrc: handle longer username and password
> https://github.com/bagder/curl/commit/15f76bf7 - Curl_setopt: handle arbitrary-length username and password
> https://github.com/bagder/curl/commit/09ddb1d6 - url: handle exceptional cases first in parse_url_login()
> https://github.com/bagder/curl/commit/455ba691 - url: Removed unused text length constants
> https://github.com/bagder/curl/commit/2f1a0bc0 - url: handle arbitrary-length username and password before '@'
> https://github.com/bagder/curl/commit/322f0bc2 - url.c: Fixed compilation warning
> https://github.com/bagder/curl/commit/169fedbd - login options: remove the ;[options] support from CURLOPT_USERPWD
> https://github.com/bagder/curl/commit/76815144 - netrc: Fixed a memory leak in an OOM condition

My first version of their backport is attached.

Comment 7 Cesar Wong 2015-09-22 17:21:51 UTC
I tested with RHEL 7.1 and the updated curl does fix the issue with the username/password truncation. Thank you!

Comment 10 Cesar Wong 2015-12-07 14:23:29 UTC
The main use case for this is that in OpenShift we use a RHEL container image as our builder. The builder needs to retrieve source code from a repository using git, which in turn uses libcurl. The internal OpenShift git server accepts tokens (which, for service accounts, are 1k in size) for authentication. With the current version of libcurl, authentication always fails for these service accounts. Therefore, our ability to build using a RHEL-based builder is limited without this fix.

Comment 18 Thomas Jones 2016-08-18 02:37:27 UTC
(In reply to Cesar Wong from comment #10)
> The main use case for this is that in OpenShift we use a RHEL container
> image as our builder. The builder needs to retrieve source code from a
> repository using git, which in turn uses libcurl. The internal OpenShift git
> server accepts tokens (which, for service accounts, are 1k in size) for
> authentication. With the current version of libcurl, authentication always
> fails for these service accounts. Therefore, our ability to build using a
> RHEL-based builder is limited without this fix.

This appears to similarly afflict the ability to use AWS CodeCommit via instance roles. Instance roles use ephemeral tokens that are transmitted via authenticated HTTPS to the CodeCommit git repositories. These tokens are similarly large in size. Right now, neither EL 6 nor EL 7 are able to use CodeCommit at provisioning-time or as part of an automated replication function (e.g., RedMine's SCM modules that pull git content into RedMine-hosted projects).

Is there a timetable for the fix mentioned in comment #7 to be pushed into EL7 (and preferable EL6 as well)?

Comment 19 Kamil Dudka 2016-08-19 08:15:43 UTC
(In reply to Thomas Jones from comment #18)
> Is there a timetable for the fix mentioned in comment #7 to be pushed into
> EL7 (and preferable EL6 as well)?

The fix is going to be included in RHEL-7.3.  There is no plan for RHEL-6 yet.

Comment 20 Thomas Jones 2016-08-19 13:03:55 UTC
(In reply to Kamil Dudka from comment #19)
> The fix is going to be included in RHEL-7.3.  There is no plan for RHEL-6
> yet.

Thanks for the update. Is this going to be via the 7.43 RPM that's available via cbs.centos.org?

Comment 21 Kamil Dudka 2016-08-19 13:50:51 UTC
(In reply to Thomas Jones from comment #20)
> Thanks for the update. Is this going to be via the 7.43 RPM that's available
> via cbs.centos.org?

Nope.  It will be curl-7.29.0-x.el7, where x >= 30.  See the Fixed In Version field on top of this page.

Comment 22 Thomas Jones 2016-10-25 12:16:18 UTC
This change will be in 7.3 or it will be released before then?

Comment 23 Kamil Dudka 2016-10-25 12:23:20 UTC
Yes, we expect the fix for this bug to be included in RHEL-7.3 GA.

Comment 25 errata-xmlrpc 2016-11-03 17:43:02 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2575.html