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 <[email protected]> > > 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
