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

[Kristian Erik Hermansen]

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



-- 
Regards,

Kristian Erik Hermansen
https://www.linkedin.com/in/kristianhermansen
https://profiles.google.com/kristianerikhermansen