On Fri, 29 Dec 2017, Kristian Erik Hermansen wrote:
Hi,
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.
Regards,
Daniel
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
...
HEAD / HTTP/1.1
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?
https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf
On Sun, Oct 29, 2017 at 3:35 PM, Daniel Stenberg <dan...@haxx.se> 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.
Example:
$ curl -H "$(echo -en 'X-Foo: foo\r\nX-Bar: bar\r\n')" 127.0.0.1:8888
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