On Wednesday 02 November 2016 at 08:12:49 +0100, Daniel Stenberg wrote:
> invalid URL parsing with '#'
> ============================
>
> Project cURL Security Advisory, November 2, 2016 -
> [Permalink](https://curl.haxx.se/docs/adv_20161102J.html)
>
> VULNERABILITY
> -------------
>
> curl doesn't parse the authority component of the URL correctly when the host
> name part ends with a '#' character, and could instead be tricked into
> connecting to a different host. This may have security implications if you for
> example use a URL parser that follows the RFC to check for allowed domains
> before using curl to request them.
>
> Passing in `http://example.com#@evil.com/x.txt` would wrongly make curl send a
> request to evil.com while your browser would connect to example.com given the
> same URL.
>
> The problem exists for most protocol schemes.
>
> We are not aware of any exploit of this flaw.
>
> INFO
> ----
>
> The Common Vulnerabilities and Exposures (CVE) project has assigned the name
> CVE-2016-8624 to this issue.

The fix for this in 3bb273db7e40ebc284cff45f3ce3f0475c8339c2 appears to
have changed the existing behaviour of file:// URLs for me:

On current master (9ea3a6e150dfc822ba1565f649b634848597d2d9):
 $ src/curl file://config.log
 curl: (37) Couldn't open file /config.log

On master with 3bb273db7e40ebc284cff45f3ce3f0475c8339c2 reverted:
 $ src/curl file://config.log
 [contents of config.log]

Rightly or wrongly, we've used URLs like "file://test.txt" in many of our
unit tests which are now failing. :(

I realise that URLs that lack the hostname part like this aren't exactly
compliant, but they have worked for rather a long time.

(This security fix has been backported to many stable distributions too
where people may not have expected such a change in behaviour.)

Mike.
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-11-04