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

[Daniel Stenberg]

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 <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.
> > >
> > > 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