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

2017-03-08 Thread 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

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

2017-03-06 Thread 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

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

2017-03-06 Thread 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

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

2017-03-06 Thread 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

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

2017-03-06 Thread 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

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

2017-03-06 Thread 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

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

2017-03-06 Thread 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

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

2017-03-06 Thread 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. >

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

2017-03-05 Thread Orange Tsai
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'