[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] [curlsec] [USN-3464-1] Wget vulnerabilities

From: Daniel Stenberg
Subject: Re: [Bug-wget] [curlsec] [USN-3464-1] Wget vulnerabilities
Date: Sat, 30 Dec 2017 09:47:11 +0100 (CET)
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

On Fri, 29 Dec 2017, Kristian Erik Hermansen wrote:


I'm currently away from home on vacation but I still want to pop in and share my view on this topic.

First: we in the curl project are totally independent from the Wget project (and virtually all other projects too) and have not even been involved or briefed about their decision process so we can of course not answer to why or how they end up with their decisions or way of acting. I fully respect them and I know they made decisions that make sense for them. But I can tell you how I view curl and how I think curl should act, and I don't think this is a security issue at all so if you want to continue and argue for a change in how curl behaves in this aspect I think a discussion on the curl-users mailing list would make sense.

You can send multiple Host: headers by using several -H options on the command line, you don't have to add them with CRLF-ones. It has always been perfectly fine and its not a hidden feature of any sorts. Many people use curl to test their servers (like for example how they handle two separate Host: headers with different contents) and the fact that you can make curl send non-compliant HTTP requests are frequently used and appreciated.

 $ curl -H "Host: one" -H "Host: two" http://example.com

You can also send headers with illegal names or illegal contents, as per the HTTP specs. curl will attempt to adhere to standards on its own, but users willing, it can be made to go wild. That's a feature, not a bug.

So no, I don't think this is a security problem in curl nor libcurl. Changing this behavior would be a pretty drastic change of curl IMO.

The main part of Orange's talk (as I recall it, I didn't check it now due to lack of bandwidth where I am at the moment) is on how different URL parsers act differently, and curl's URL parser has been made stricter lately and does not allow the specific things he outlines in his talk. I don't think the way we handle custom added headers is the same kind of problem, since that's not a standard or spec-designed feature.


I still contend that this is at least a bug, and potentially a
security issue, but only when the headers are ones that should NEVER
have multiple values. Consider the "Host" header. It seems a bug to
allow TWO Host header values, but this is possible. It is also
possible to append newlines into the Host headers, which seems wrong
too. wget specifically patched the "Host" header issues. I agree with
you that other headers should be OK to be manipulated this way, but
Host header should be treated differently, yes?

$ curl -s -I -H "$(echo -en "Host: foo.example.com\r\nHost:
bar.example.com")" localhost
Host: foo.example.com
Host: bar.example.com

Perhaps the Orange Tsai, the original reporter of the vulnerabilities,
or wget maintainers can elaborate for us on why wget was patched but
curl team doesn't think it's a vulnerability?


On Sun, Oct 29, 2017 at 3:35 PM, Daniel Stenberg <address@hidden> wrote:
On Sun, 29 Oct 2017, Kristian Erik Hermansen via curlsec wrote:

This is a bug??? Not sure if this is exactly the same "bug" or not as the
CVE? I have been using that for YEARS. It's a security issue? OK, then well
curl is also affected and should be patched. Let's get a CVE going from
upstream reporting to curl dev if it's the same thing.


$ curl -H "$(echo -en 'X-Foo: foo\r\nX-Bar: bar\r\n')"

I don't consider this a bug but rather a (subtle) feature that I personally
even have suggested to users to use at times. If this is a surprise to
anyone I think it should rather be better clarified in the documentation.


 / daniel.haxx.se


 / daniel.haxx.se

reply via email to

[Prev in Thread] Current Thread [Next in Thread]