I recently came across a very interesting, and potentially exploitable, problem while working on keep.sh.
I was uploading a file with an Authorization header from a curl client and noticed a strange behavior. During a redirect, the Authorization header stayed with the request even though it was redirected to a different domain.
This sparked my interest as this was clearly undesired behavior and a possible security issue.
A quick Google search led me to CVE-2018-1000007.
When asked to send custom headers in its HTTP requests, curl will send that set of headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.
Sending the same set of headers to subsequent hosts is, in particular, a problem for applications that pass on custom Authorization: headers, as this header often contains privacy-sensitive information or data that could allow others to impersonate the curl-using client's request.
We are not aware of any exploit of this flaw.
This security vulnerability has been patched within curl for well over a year but still largely exists in the wild. As of today’s writing, the vulnerability still exists on my MacBook Pro which runs Curl 7.54 natively if you have not specifically updated it using Homebrew or another solution.
This security vulnerability caused a large headache for our service as we rely on the Authorization header for our premium offerings. (Coming Soon!)
This vulnerability prevents our customers from safely downloading their files from our service as it leaks their Authorization information to third party providers.
When you download a file from our service, we currently return a signed URL that redirects to our Digital Ocean space. This allows for your download to start immediately without us having to be a middle-man that fetches the file from our servers and then relay it to you.
This approach speeds up the request and reduces server demand. Herein lies the problem — if your version of curl is vulnerable to a signed redirect, you may be leaking your keys during this redirect.
There was a lot of internal discussion on how to solve this problem to prevent our customers from unknowingly exposing their private keys.
Do we detect the requesting curl version and simply block the request? Do we allow our customers to use a curl version with this security vulnerability and show a warning? Do we abandon the use of redirects?
To make finding a solution even more difficult — we cannot simply detect and rely on the curl version as patches were released for older versions. This means that if you are using an older version of curl it may or may not be vulnerable.
In the end, we had to get creative to solve this complicated issue. We created a two-part system to detect if the incoming requests have this vulnerability and then block the vulnerable requests with a notice.
When a download is first received, our system inspects the User-Agent header for the version of curl you are using. This is done to check if you are using an older version of curl that may be vulnerable.
/**
* Determines if a curl request may be vulnerable to CVE-2018-1000007
*
* @param Request $request
* @return bool
*/
protected function curlMayBeVulnerable(Request $request)
{
if (! $request->hasHeader('Authorization')) {
return false;
}
[$agent, $version] = explode('/', $request->userAgent());
$version = new Version($version);
$vulnerableVersion = new Version('7.58.0');
if ($version->lt($vulnerableVersion)) {
return true;
}
return false;
}
Once we determine that you are using a version of curl that may be vulnerable, we send a redirect to a separate secure domain controlled by us.
This behavior mimics the actual security vulnerability without exposing your private keys to an outside organization.
This specially-crafted redirect simply checks if the Authorization headers are still present. If they are (and they shouldn’t be), this means that your current version of curl is vulnerable to CVE-2018–1000007.
After we determine that you are vulnerable to this attack, we actively block the request from continuing and show an error message on your console:
The version of curl you are using has a known security vulnerability that prevents us from safely allowing you to download your files. See [https://curl.haxx.se/docs/CVE-2018-1000007.html](https://curl.haxx.se/docs/CVE-2018-1000007.html) for more information.
Balancing security with convenience is a constant battle. We could have easily just ignored the issue and allowed our customers to expose their Authorization header to an outside organization while retrieving their files.
We believed, even though it can potentially take away from the experience, that blocking all vulnerable requests is the best course of action. This protects our users and their files.
keep.sh is a free file transfer service that allows you to transfer files easily with a simple command line on any server. We recommend you try it today! curl — upload-file file.txt
Top comments (0)