November 2011 - tor-commits - lists.torproject.org

[tor/master] Add a changes file for 4410
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit be6928d6e78a47800a96962403efff753ad70e84 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Sun Nov 6 17:24:09 2011 +0100 Add a changes file for 4410 --- changes/bug4410 | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/changes/bug4410 b/changes/bug4410 new file mode 100644 index 0000000..f42893a --- /dev/null +++ b/changes/bug4410 @@ -0,0 +1,5 @@ + o Major bugfixes: + - Correctly sanity-check that we don't underflow on a memory allocation + for introduction point decryption. Bug discovered by Dan Rosenberg. + Fixes bug 4410; bugfix on 0.2.1.5-alpha. +

1 0

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.1' into maint-0.2.2
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit 4d8306e0e92200e1a25a073480ec342e22e590b7 Merge: 9725646 be6928d Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Nov 7 10:42:34 2011 -0500 Merge remote-tracking branch 'origin/maint-0.2.1' into maint-0.2.2 changes/bug4410 | 5 +++++ src/or/routerparse.c | 5 +++++ 2 files changed, 10 insertions(+), 0 deletions(-)

1 0

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.2'
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit 51f53b590ee15c972adcff9e7d94c904a9267ac2 Merge: 350fe95 4d8306e Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Nov 7 10:44:02 2011 -0500 Merge remote-tracking branch 'origin/maint-0.2.2' changes/bug4410 | 5 +++++ src/or/routerparse.c | 5 +++++ 2 files changed, 10 insertions(+), 0 deletions(-)

1 0

[tor/master] Fix remotely triggerable assert during ip decryption
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit d5161ab895b9c14a66a08fb38521dd12c0772a97 Author: Dan Rosenberg <dan.j.rosenberg(a)gmail.com> Date: Sun Nov 6 17:23:14 2011 +0100 Fix remotely triggerable assert during ip decryption Fixes bug 4410. --- src/or/routerparse.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/or/routerparse.c b/src/or/routerparse.c index 19f9e38..843fc79 100644 --- a/src/or/routerparse.c +++ b/src/or/routerparse.c @@ -3858,6 +3858,11 @@ rend_decrypt_introduction_points(char **ipos_decrypted, crypto_cipher_env_t *cipher; char *dec; int declen; + if (ipos_encrypted_size < CIPHER_IV_LEN + 2) { + log_warn(LD_REND, "Size of encrypted introduction points is too " + "small."); + return -1; + } dec = tor_malloc_zero(ipos_encrypted_size - CIPHER_IV_LEN - 1); cipher = crypto_create_init_cipher(descriptor_cookie, 0); declen = crypto_cipher_decrypt_with_iv(cipher, dec,

1 0

[tor/maint-0.2.2] Fix remotely triggerable assert during ip decryption
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit d5161ab895b9c14a66a08fb38521dd12c0772a97 Author: Dan Rosenberg <dan.j.rosenberg(a)gmail.com> Date: Sun Nov 6 17:23:14 2011 +0100 Fix remotely triggerable assert during ip decryption Fixes bug 4410. --- src/or/routerparse.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/or/routerparse.c b/src/or/routerparse.c index 19f9e38..843fc79 100644 --- a/src/or/routerparse.c +++ b/src/or/routerparse.c @@ -3858,6 +3858,11 @@ rend_decrypt_introduction_points(char **ipos_decrypted, crypto_cipher_env_t *cipher; char *dec; int declen; + if (ipos_encrypted_size < CIPHER_IV_LEN + 2) { + log_warn(LD_REND, "Size of encrypted introduction points is too " + "small."); + return -1; + } dec = tor_malloc_zero(ipos_encrypted_size - CIPHER_IV_LEN - 1); cipher = crypto_create_init_cipher(descriptor_cookie, 0); declen = crypto_cipher_decrypt_with_iv(cipher, dec,

1 0

[tor/maint-0.2.2] Add a changes file for 4410
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit be6928d6e78a47800a96962403efff753ad70e84 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Sun Nov 6 17:24:09 2011 +0100 Add a changes file for 4410 --- changes/bug4410 | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/changes/bug4410 b/changes/bug4410 new file mode 100644 index 0000000..f42893a --- /dev/null +++ b/changes/bug4410 @@ -0,0 +1,5 @@ + o Major bugfixes: + - Correctly sanity-check that we don't underflow on a memory allocation + for introduction point decryption. Bug discovered by Dan Rosenberg. + Fixes bug 4410; bugfix on 0.2.1.5-alpha. +

1 0

[tor/maint-0.2.2] Merge remote-tracking branch 'origin/maint-0.2.1' into maint-0.2.2
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit 4d8306e0e92200e1a25a073480ec342e22e590b7 Merge: 9725646 be6928d Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Nov 7 10:42:34 2011 -0500 Merge remote-tracking branch 'origin/maint-0.2.1' into maint-0.2.2 changes/bug4410 | 5 +++++ src/or/routerparse.c | 5 +++++ 2 files changed, 10 insertions(+), 0 deletions(-)

1 0

[tor/maint-0.2.1] Fix remotely triggerable assert during ip decryption
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit d5161ab895b9c14a66a08fb38521dd12c0772a97 Author: Dan Rosenberg <dan.j.rosenberg(a)gmail.com> Date: Sun Nov 6 17:23:14 2011 +0100 Fix remotely triggerable assert during ip decryption Fixes bug 4410. --- src/or/routerparse.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/or/routerparse.c b/src/or/routerparse.c index 19f9e38..843fc79 100644 --- a/src/or/routerparse.c +++ b/src/or/routerparse.c @@ -3858,6 +3858,11 @@ rend_decrypt_introduction_points(char **ipos_decrypted, crypto_cipher_env_t *cipher; char *dec; int declen; + if (ipos_encrypted_size < CIPHER_IV_LEN + 2) { + log_warn(LD_REND, "Size of encrypted introduction points is too " + "small."); + return -1; + } dec = tor_malloc_zero(ipos_encrypted_size - CIPHER_IV_LEN - 1); cipher = crypto_create_init_cipher(descriptor_cookie, 0); declen = crypto_cipher_decrypt_with_iv(cipher, dec,

1 0

[tor/maint-0.2.1] Add a changes file for 4410
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit be6928d6e78a47800a96962403efff753ad70e84 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Sun Nov 6 17:24:09 2011 +0100 Add a changes file for 4410 --- changes/bug4410 | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/changes/bug4410 b/changes/bug4410 new file mode 100644 index 0000000..f42893a --- /dev/null +++ b/changes/bug4410 @@ -0,0 +1,5 @@ + o Major bugfixes: + - Correctly sanity-check that we don't underflow on a memory allocation + for introduction point decryption. Bug discovered by Dan Rosenberg. + Fixes bug 4410; bugfix on 0.2.1.5-alpha. +

1 0

[torspec/master] Add proposals/189-authorize-cell.txt.
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit 067ba228365a0262e08c0af9a8da16d5d35e1a62 Author: George Kadianakis <desnacked(a)gmail.com> Date: Fri Nov 4 18:38:51 2011 +0100 Add proposals/189-authorize-cell.txt. --- proposals/189-authorize-cell.txt | 122 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 122 insertions(+), 0 deletions(-) diff --git a/proposals/189-authorize-cell.txt b/proposals/189-authorize-cell.txt new file mode 100644 index 0000000..10b45a2 --- /dev/null +++ b/proposals/189-authorize-cell.txt @@ -0,0 +1,122 @@ +Filename: 189-authorize-cell.txt +Title: AUTHORIZE and AUTHORIZED cells +Author: George Kadianakis +Created: 04 Nov 2011 +Status: Open + +1. Overview + + Proposal 187 introduced the concept of the AUTHORIZE cell, a cell + whose purpose is to make Tor bridges resistant to scanning attacks. + + This is achieved by having the bridge and the client share a secret + out-of-band and then use AUTHORIZE cells to validate that the + client indeed knows that secret before proceeding with the Tor + protocol. + + This proposal specifies the format of the AUTHORIZE cell and also + introduces the AUTHORIZED cell, a way for bridges to announce to + clients that the authorization process is complete and successful. + +2. Motivation + + AUTHORIZE cells should be able to perform a variety of + authorization protocols based on a variety of shared secrets. This + forces the AUTHORIZE cell to have a dynamic format based on the + authorization method used. + + AUTHORIZED cells are used by bridges to signal the end of a + successful bridge client authorization and the beginning of the + actual link handshake. AUTHORIZED cells have no other use and for + this reason their format is very simple. + + Both AUTHORIZE and AUTHORIZED cells are to be used under censorship + conditions and they should look innocuous to any adversary capable + of monitoring network traffic. + + As an attack example, an adversary could passively monitor the + traffic of a bridge host, looking at the packets directly after the + TLS handshake and trying to deduce from their packet size if they + are AUTHORIZE and AUTHORIZED cells. For this reason, AUTHORIZE and + AUTHORIZED cells are padded with a random amount of padding before + sending. + +3. Design + +3.1. AUTHORIZE cell + + The AUTHORIZE cell is a variable-sized cell. + + The generic AUTHORIZE cell format is: + + AuthMethod [1 octet] + MethodFields [...] + PadLen [2 octets] + Padding ['PadLen' octets] + + where: + + 'AuthMethod', is the authorization method to be used. + + 'MethodFields', is dependent on the authorization Method used. It's + a meta-field hosting an arbitrary amount of fields. + + 'PadLen', specifies the amount of padding in octets. + + 'Padding', is 'PadLen' octets of random content. + +3.2. AUTHORIZED cell format + + The AUTHORIZED cell is a variable-sized cell. + + The AUTHORIZED cell format is: + + 'AuthMethod' [1 octet] + 'PadLen' [2 octets] + 'Padding' ['PadLen' octets] + + where all fields have the same meaning as in section 3.1. + +3.3. Cell parsing + + Implementations MUST ignore the contents of 'Padding'. + + Implementations MUST reject an AUTHORIZE or AUTHORIZED cell where + the 'Padding' field is not 'PadLen' octets long. + + Implementations MUST reject an AUTHORIZE cell with an 'AuthMethod' + they don't recognize. + +4. Discussion + +4.1. Why not let the pluggable transports do the padding, like they + are supposed to do for the rest of the Tor protocol? + + The arguments of section "Alternative design: Just use pluggable + transports" of proposal 187, apply here as well: + + All bridges who use client authorization will also need camouflaged + AUTHORIZE/AUTHORIZED cell. + +4.2. How should multiple round-trip authorization protocols be handled? + + Protocols that require multiple round-trips between the client and + the bridge should use AUTHORIZE cells for communication. + + The format of the AUTHORIZE cell is flexible enough to support + messages from the client to the bridge and the inverse. + + In the end of a successful multiple round-trip protocol, an + AUTHORIZED cell must be issued from the bridge to the client. + +4.3. AUTHORIZED seems useless. Why not use VPADDING instead? + + As noted in proposal 187, the Tor protocol uses VPADDING cells for + padding; any other use of VPADDING makes the Tor protocol kludgy. + + In the future, and in the example case of a v3 handshake, a client + can optimistically send a VERSIONS cell along with the final + AUTHORIZE cell of an authorization protocol. That allows the + bridge, in the case of successful authorization, to also process + the VERSIONS cell and begin the v3 handshake promptly. +

1 0