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

[Tim Ruehsen]

Hi,

I am the current maintainer of Wget.

Regarding the double Host: entries I totally agree with Daniel - there
is no vulnerability in generating/sending. It would be a nice feature
to have, though (didn't test if it works out of the box).

What we fixed are CVE-2017-13089 and CVE-2017-13090. The other CVE's
(CVE-2016-7098, CVE-2017-6508) haven't been reported to Wget (at least
not that I remember).

Just for reference: https://usn.ubuntu.com/usn/usn-3464-1/

Regards, Tim

Am Samstag, den 30.12.2017, 09:47 +0100 schrieb 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-O
> > f-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
> > 
> > 
> > 
> > 
> 
>

signature.asc
Description: This is a digitally signed message part