[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #29175 [Core Tor/Tor]: Tor 0.3.5.x mishandles empty socks5 auth
#29175: Tor 0.3.5.x mishandles empty socks5 auth
--------------------------------------+------------------------------------
Reporter: arma | Owner: rl1987
Type: defect | Status: accepted
Priority: High | Milestone: Tor: 0.4.0.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: regression, 035-backport | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------------------+------------------------------------
Old description:
> There is a regression in Tor 0.3.5.x with handling socks5 handshakes that
> offer username/password auth but then present empty username and
> password.
>
> It came in during commit 9068ac3c (which went into 0.3.5.1-alpha).
>
> The symptom is that when you do your socks5 handshake with an empty
> username and password (e.g. like pidgin does it), you get log lines like
> {{{
> Jan 24 19:40:17.000 [warn] Fetching socks handshake failed. Closing.
> Jan 24 19:40:17.000 [warn] socks5: parsing failed - invalid user/pass
> authentication message.
> }}}
>
> Bug reported by a person on #tor, and also separately by #29050.
>
> I asked Josh Glazebrook, the author of the socks library in #29050, for
> some actual traces of correct behavior / incorrect behavior, and he sent:
>
> {{{
> ocks v2.2.3
> tor v0.3.5.7
> client announces it only supports noauth (00)
> server chooses noauth (00)
>
> send <Buffer 05 01 00> [00 = noauth]
> recv <Buffer 05 00> [server chose noauth]
> send <Buffer 05 01 00 03 09 69 70 69 6e 66 6f 2e 69 6f 00 50> [connect
> command - ipinfo.io]
> recv <Buffer 05 00 00 01 00> [success]
>
>
> socks v2.2.2
> tor v0.3.5.7
> client announces it supports noauth (00) and userpass (02)
> server chooses userpass (02)
> connection is unsuccessful - server returns general socks server failure,
> tor logs indicate invalid user/pass.
> Jan 24 14:47:15.000 [warn] Fetching socks handshake failed. Closing.
> Jan 24 14:47:56.000 [warn] socks5: parsing failed - invalid user/pass
> authentication message.
>
> send <Buffer 05 02 00 02> [00 = noauth, 02 = userpass]
> recv <Buffer 05 02> [server chose userpass]
> send <Buffer 01 00 00> [00 = zero length username, 00 = zero length
> password]
> recv <Buffer 01 00> [00 = server indicates auth success]
> send <Buffer 05 01 00 03 09 69 70 69 6e 66 6f 2e 69 6f 00 50> [connect
> command - ipinfo.io]
> recv <Buffer 05 01 00 01 00> [01- general SOCKS server failure] (in tor's
> log output it's saying auth is invalid at this point)
>
>
> socks v.2.2.2
> tor via torbrowser 8.0.4 (unsure of which tor version, but likely older
> than 0.3.5.7)
> client announces it supports noauth (00) and userpass (02)
> server chooses userpass (02)
> connection is successful
>
> send <Buffer 05 02 00 02> [00 = noauth, 02 = userpass]
> recv <Buffer 05 02> [server chose userpass]
> send <Buffer 01 00 00> [00 = zero length username, 00 = zero length
> password]
> recv <Buffer 01 00> [00 = server indicates auth success]
> send <Buffer 05 01 00 03 09 69 70 69 6e 66 6f 2e 69 6f 00 50> [connect
> command - ipinfo.io]
> recv <Buffer 05 00 00 01 00> [00 = success]
> }}}
>
> Josh further gives us this hint:
>
> {{{
> It appears there is indeed something that changed between older versions
> of
> Tor and newer versions. Looking at the actual data being exchanged, it's
> exactly the same.
>
> The only odd thing is tor v0.3.5.7 is indicating in the auth reply that
> the
> authentication was a success, and only when the connect command is sent,
> it's returning a "general socks server failure" code, but in the actual
> tor
> log it's logging invalid user/pass.
> }}}
>
> I went spelunking and found this code newly in 0.3.5.x:
>
> {{{
> if (usernamelen && username) {
> tor_free(req->username);
> req->username = tor_memdup_nulterm(username, usernamelen);
> req->usernamelen = usernamelen;
>
> req->got_auth = 1;
> }
>
> if (passwordlen && password) {
> tor_free(req->password);
> req->password = tor_memdup_nulterm(password, passwordlen);
> req->passwordlen = passwordlen;
>
> req->got_auth = 1;
> }
> }}}
>
> Compare to the code in 0.3.4.x:
> {{{
> if (usernamelen) {
> req->username = tor_memdup(data+2u, usernamelen);
> req->usernamelen = usernamelen;
> }
> if (passlen) {
> req->password = tor_memdup(data+3u+usernamelen, passlen);
> req->passwordlen = passlen;
> }
> *drain_out = 2u + usernamelen + 1u + passlen;
> req->got_auth = 1;
> }}}
>
> So in 0.3.4.x when we got a type 0x02 handshake but empty username and
> empty password, we would still set got_auth to 1. In 0.3.5.x when that
> happens, we leave got_auth at 0.
>
> The result is that the socks5 handshake itself still goes identically,
> but when we get the empty username and password, we '''don't record that
> we received it''', even though we send back a "handshake was successful"
> response. And then when application data shows up after that, we try to
> treat it as a socks5 username and password, because we're still waiting
> for one. That's where things go bad.
New description:
There is a regression in Tor 0.3.5.x with handling socks5 handshakes that
offer username/password auth but then present empty username and password.
It came in during commit 9068ac3c (which went into 0.3.5.1-alpha).
The symptom is that when you do your socks5 handshake with an empty
username and password (e.g. like pidgin does it), you get log lines like
{{{
Jan 24 19:40:17.000 [warn] Fetching socks handshake failed. Closing.
Jan 24 19:40:17.000 [warn] socks5: parsing failed - invalid user/pass
authentication message.
}}}
Bug reported by a person on #tor, and also separately by #29050.
I asked Josh Glazebrook, the author of the socks library in #29050, for
some actual traces of correct behavior / incorrect behavior, and he sent:
{{{
socks v2.2.3
tor v0.3.5.7
client announces it only supports noauth (00)
server chooses noauth (00)
send <Buffer 05 01 00> [00 = noauth]
recv <Buffer 05 00> [server chose noauth]
send <Buffer 05 01 00 03 09 69 70 69 6e 66 6f 2e 69 6f 00 50> [connect
command - ipinfo.io]
recv <Buffer 05 00 00 01 00> [success]
socks v2.2.2
tor v0.3.5.7
client announces it supports noauth (00) and userpass (02)
server chooses userpass (02)
connection is unsuccessful - server returns general socks server failure,
tor logs indicate invalid user/pass.
Jan 24 14:47:15.000 [warn] Fetching socks handshake failed. Closing.
Jan 24 14:47:56.000 [warn] socks5: parsing failed - invalid user/pass
authentication message.
send <Buffer 05 02 00 02> [00 = noauth, 02 = userpass]
recv <Buffer 05 02> [server chose userpass]
send <Buffer 01 00 00> [00 = zero length username, 00 = zero length
password]
recv <Buffer 01 00> [00 = server indicates auth success]
send <Buffer 05 01 00 03 09 69 70 69 6e 66 6f 2e 69 6f 00 50> [connect
command - ipinfo.io]
recv <Buffer 05 01 00 01 00> [01- general SOCKS server failure] (in tor's
log output it's saying auth is invalid at this point)
socks v.2.2.2
tor via torbrowser 8.0.4 (unsure of which tor version, but likely older
than 0.3.5.7)
client announces it supports noauth (00) and userpass (02)
server chooses userpass (02)
connection is successful
send <Buffer 05 02 00 02> [00 = noauth, 02 = userpass]
recv <Buffer 05 02> [server chose userpass]
send <Buffer 01 00 00> [00 = zero length username, 00 = zero length
password]
recv <Buffer 01 00> [00 = server indicates auth success]
send <Buffer 05 01 00 03 09 69 70 69 6e 66 6f 2e 69 6f 00 50> [connect
command - ipinfo.io]
recv <Buffer 05 00 00 01 00> [00 = success]
}}}
Josh further gives us this hint:
{{{
It appears there is indeed something that changed between older versions
of
Tor and newer versions. Looking at the actual data being exchanged, it's
exactly the same.
The only odd thing is tor v0.3.5.7 is indicating in the auth reply that
the
authentication was a success, and only when the connect command is sent,
it's returning a "general socks server failure" code, but in the actual
tor
log it's logging invalid user/pass.
}}}
I went spelunking and found this code newly in 0.3.5.x:
{{{
if (usernamelen && username) {
tor_free(req->username);
req->username = tor_memdup_nulterm(username, usernamelen);
req->usernamelen = usernamelen;
req->got_auth = 1;
}
if (passwordlen && password) {
tor_free(req->password);
req->password = tor_memdup_nulterm(password, passwordlen);
req->passwordlen = passwordlen;
req->got_auth = 1;
}
}}}
Compare to the code in 0.3.4.x:
{{{
if (usernamelen) {
req->username = tor_memdup(data+2u, usernamelen);
req->usernamelen = usernamelen;
}
if (passlen) {
req->password = tor_memdup(data+3u+usernamelen, passlen);
req->passwordlen = passlen;
}
*drain_out = 2u + usernamelen + 1u + passlen;
req->got_auth = 1;
}}}
So in 0.3.4.x when we got a type 0x02 handshake but empty username and
empty password, we would still set got_auth to 1. In 0.3.5.x when that
happens, we leave got_auth at 0.
The result is that the socks5 handshake itself still goes identically, but
when we get the empty username and password, we '''don't record that we
received it''', even though we send back a "handshake was successful"
response. And then when application data shows up after that, we try to
treat it as a socks5 username and password, because we're still waiting
for one. That's where things go bad.
--
Comment (by arma):
(fixing mis-paste in josh's text)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29175#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs