Re: [Bug-wget] Vulnerability Report - CRLF Injection in Wget Host Part

[Dale R. Worley]

Ander Juaristi  writes:
> On 06/03/17 16:47, Dale R. Worley wrote:
>> Orange Tsai  writes:
>>> # This will work
>>> $ wget 'http://127.0.0.1%0d%0aCookie%3a hi%0a/'
>> 
>> Not even considering the effect on headers, it's surprising that wget
>> doesn't produce an immediate error, since
>> "127.0.0.1%0d%0aCookie%3a hi%0a" is syntactically invalid as a host
>> part.  Why doesn't wget's URL parser detect that?
>
> Simply because it first splits the URL into several parts according to
> the delimiters, and then decodes the percent-encoding.
>
> Additionally for the host part it also checks whether it's an IP address
> and the IDNA stuff, but yeah you raise a good point. Other than that the
> host part is treated similarly to the other parts.

Ah, I looked into RFC 3986, and the generic syntax *does* allow the host
part to contain %-escapes.  But in any case,
"127.0.0.1Cookie:hi" is not parsable as an IPv4
address.  (Always beware of parsing functions that stop when they see
the first invalid character!)

(Also, shouldn't the above example have ended "hi%0d%0a/"?)

Dale

Re: [Bug-wget] Vulnerability Report - CRLF Injection in Wget Host Part

[Orange Tsai]

Oops

That my fault. I sent the wrong mail.

Very sorry :(

2017-03-07 3:03 GMT+08:00 Tim Rühsen :

> On Dienstag, 7. März 2017 02:01:06 CET Orange Tsai wrote:
> > I am surprise that `http://u...@evil.com:8...@good.com` will connect to `
> > evil.com`, not `good.com`.
> > Most of URL parser will recognize `good.com` is host part. Like this
> > advisory, https://curl.haxx.se/docs/adv_20161102J.html
> > It seem more dangerous if a developer still rely on the result of parse
> URL
> > than my original report.
> >
> > Some testing:
> > $ python try.py 'http://user@127.3.3.3:80@127.2.2.2/x'
> >
> > Python scheme=http, host=user@127.3.3.3:80@127.2.2.2, port=
> > PHP scheme=http, host=127.2.2.2, port=
> > Perl scheme=http, host=127.2.2.2, port=80
> > Ruby2 scheme=http, host=127.2.2.2, port=
> > GO scheme=http, host=127.2.2.2, port=
> > Java scheme=http, host=, port=-1
> > JS scheme=http, host=127.2.2.2, port=null
> >
> >
> >
> > But it seems also the same root cause and fixed at this patch. :)
> > By the way, would you mind that allocating a CVE-ID to address this?
>
> I'd appreciate that. But I never did that, so who does allocate a CVE how
> and
> where ? I am willing to learn :-)
>
> Tim
>



-- 
- Orange -

Re: [Bug-wget] Vulnerability Report - CRLF Injection in Wget Host Part

[Orange Tsai]

But still thanks :)
I will try to ask for allocating a CVE from https://cve.mitre.org/


2017-03-07 3:05 GMT+08:00 Orange Tsai :

> Oops
>
> That my fault. I sent the wrong mail.
>
> Very sorry :(
>
> 2017-03-07 3:03 GMT+08:00 Tim Rühsen :
>
>> On Dienstag, 7. März 2017 02:01:06 CET Orange Tsai wrote:
>> > I am surprise that `http://u...@evil.com:8...@good.com` will connect to `
>> > evil.com`, not `good.com`.
>> > Most of URL parser will recognize `good.com` is host part. Like this
>> > advisory, https://curl.haxx.se/docs/adv_20161102J.html
>> > It seem more dangerous if a developer still rely on the result of parse
>> URL
>> > than my original report.
>> >
>> > Some testing:
>> > $ python try.py 'http://user@127.3.3.3:80@127.2.2.2/x'
>> >
>> > Python scheme=http, host=user@127.3.3.3:80@127.2.2.2, port=
>> > PHP scheme=http, host=127.2.2.2, port=
>> > Perl scheme=http, host=127.2.2.2, port=80
>> > Ruby2 scheme=http, host=127.2.2.2, port=
>> > GO scheme=http, host=127.2.2.2, port=
>> > Java scheme=http, host=, port=-1
>> > JS scheme=http, host=127.2.2.2, port=null
>> >
>> >
>> >
>> > But it seems also the same root cause and fixed at this patch. :)
>> > By the way, would you mind that allocating a CVE-ID to address this?
>>
>> I'd appreciate that. But I never did that, so who does allocate a CVE how
>> and
>> where ? I am willing to learn :-)
>>
>> Tim
>>
>
>
>
> --
> - Orange -
>



-- 
- Orange -

Re: [Bug-wget] Vulnerability Report - CRLF Injection in Wget Host Part

[Tim Rühsen]

On Dienstag, 7. März 2017 02:01:06 CET Orange Tsai wrote:
> I am surprise that `http://u...@evil.com:8...@good.com` will connect to `
> evil.com`, not `good.com`.
> Most of URL parser will recognize `good.com` is host part. Like this
> advisory, https://curl.haxx.se/docs/adv_20161102J.html
> It seem more dangerous if a developer still rely on the result of parse URL
> than my original report.
> 
> Some testing:
> $ python try.py 'http://user@127.3.3.3:80@127.2.2.2/x'
> 
> Python scheme=http, host=user@127.3.3.3:80@127.2.2.2, port=
> PHP scheme=http, host=127.2.2.2, port=
> Perl scheme=http, host=127.2.2.2, port=80
> Ruby2 scheme=http, host=127.2.2.2, port=
> GO scheme=http, host=127.2.2.2, port=
> Java scheme=http, host=, port=-1
> JS scheme=http, host=127.2.2.2, port=null
> 
> 
> 
> But it seems also the same root cause and fixed at this patch. :)
> By the way, would you mind that allocating a CVE-ID to address this?

I'd appreciate that. But I never did that, so who does allocate a CVE how and 
where ? I am willing to learn :-)

Tim


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

Re: [Bug-wget] Vulnerability Report - CRLF Injection in Wget Host Part

[Orange Tsai]

I am surprise that `http://u...@evil.com:8...@good.com` will connect to `
evil.com`, not `good.com`.
Most of URL parser will recognize `good.com` is host part. Like this
advisory, https://curl.haxx.se/docs/adv_20161102J.html
It seem more dangerous if a developer still rely on the result of parse URL
than my original report.

Some testing:
$ python try.py 'http://user@127.3.3.3:80@127.2.2.2/x'

Python scheme=http, host=user@127.3.3.3:80@127.2.2.2, port=
PHP scheme=http, host=127.2.2.2, port=
Perl scheme=http, host=127.2.2.2, port=80
Ruby2 scheme=http, host=127.2.2.2, port=
GO scheme=http, host=127.2.2.2, port=
Java scheme=http, host=, port=-1
JS scheme=http, host=127.2.2.2, port=null



But it seems also the same root cause and fixed at this patch. :)
By the way, would you mind that allocating a CVE-ID to address this?

2017-03-07 0:11 GMT+08:00 Eli Zaretskii :

> > From: Tim Ruehsen 
> > Date: Mon, 06 Mar 2017 10:17:25 +0100
> > Cc: Orange Tsai 
> >
> > Thanks, just pushed a commit, not allowing control chars in host part.
>
> Hmm... is it really enough to reject only ASCII control characters?
> Maybe we should also reject control characters from other Unicode
> ranges?  Just a thought.
>



-- 
- Orange -

Re: [Bug-wget] Vulnerability Report - CRLF Injection in Wget Host Part

[Eli Zaretskii]

> From: Tim Ruehsen 
> Date: Mon, 06 Mar 2017 10:17:25 +0100
> Cc: Orange Tsai 
> 
> Thanks, just pushed a commit, not allowing control chars in host part.

Hmm... is it really enough to reject only ASCII control characters?
Maybe we should also reject control characters from other Unicode
ranges?  Just a thought.

Re: [Bug-wget] Vulnerability Report - CRLF Injection in Wget Host Part

[Dale R. Worley]

Orange Tsai  writes:
> # This will work
> $ wget 'http://127.0.0.1%0d%0aCookie%3a hi%0a/'

Not even considering the effect on headers, it's surprising that wget
doesn't produce an immediate error, since
"127.0.0.1%0d%0aCookie%3a hi%0a" is syntactically invalid as a host
part.  Why doesn't wget's URL parser detect that?  I'm sure the new
patch is an improvement, but it's surprising that the old code didn't
detect that was an invalid URL anyway, since it contains characters that
aren't permitted in those locations.

Dale

Re: [Bug-wget] Vulnerability Report - CRLF Injection in Wget Host Part

[Tim Ruehsen]

On Monday, March 6, 2017 3:42:24 AM CET Orange Tsai wrote:
> Hi
> 
> I just found that there is a CRLF Injection in the latest version of Wget
> 1.19.
> 
> Wget uses urlencode to encode CRLF in PATH part but doesn't use in HOST
> port. So an attacker can inject arbitrary header in the request.
> 
> 
> For example:
> 
> # This will fail
> $ wget 'http://127.0.0.1/%0d%0Cookie: hi'
> 
> GET /%0d%0Cookie:%20hi HTTP/1.1
> User-Agent: Wget/1.19 (linux-gnu)
> Accept: */*
> Accept-Encoding: identity
> Host: 127.0.0.1
> Connection: Keep-Alive
> 
> 
> # This will work
> $ wget 'http://127.0.0.1%0d%0aCookie%3a hi%0a/'
> 
> GET / HTTP/1.1
> User-Agent: Wget/1.19 (linux-gnu)
> Accept: */*
> Accept-Encoding: identity
> Host: [127.0.0.1
> *cookie: hi*
> ]
> Connection: Keep-Alive
> 
> 
> Wish you aware this, thanks for your reading :)

Thanks, just pushed a commit, not allowing control chars in host part.

Regards, Tim


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