April 2019 - tor-commits - lists.torproject.org

[tor/release-0.4.0] Merge branch 'maint-0.4.0' into release-0.4.0
by nickm＠torproject.org 10 Apr '19

10 Apr '19

commit dcce26331cc7e84a04f907b1bc790596bf9a759f Merge: 4000666ee b2fc57426 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Apr 10 11:52:23 2019 -0400 Merge branch 'maint-0.4.0' into release-0.4.0 configure.ac | 4 ++-- contrib/win32build/tor-mingw.nsi.in | 2 +- src/win32/orconfig.h | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-)

1 0

[tor/master] Merge branch 'maint-0.4.0'
by nickm＠torproject.org 10 Apr '19

10 Apr '19

commit 3c64cfe649be78c738fa8175d94ad9a0db37ef87 Merge: 3be1e26b8 b2fc57426 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Apr 10 11:52:12 2019 -0400 Merge branch 'maint-0.4.0'

1 0

[tor/maint-0.4.0] Add changes file for #30040.
by nickm＠torproject.org 10 Apr '19

10 Apr '19

commit 2cdc6b2005d2ad09b44cf9a455a70f258e7f6fca Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue Apr 9 17:30:14 2019 +0300 Add changes file for #30040. --- changes/bug30040 | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/changes/bug30040 b/changes/bug30040 new file mode 100644 index 000000000..7d80528a1 --- /dev/null +++ b/changes/bug30040 @@ -0,0 +1,9 @@ + o Minor bugfixes (security): + - Fix a potential double free bug when reading huge bandwidth files. The + issue is not exploitable in the current Tor network because the + vulnerable code is only reached when directory authorities read bandwidth + files, but bandwidth files come from a trusted source (usually the + authorities themselves). Furthermore, the issue is only exploitable in + rare (non-POSIX) 32-bit architectures which are not used by any of the + current authorities. Fixes bug 30040; bugfix on 0.3.5.1-alpha. Bug found + and fixed by Tobias Stoeckmann.

1 0

[tor/maint-0.4.0] Merge remote-tracking branch 'tor-github/pr/926' into maint-0.4.0
by nickm＠torproject.org 10 Apr '19

10 Apr '19

commit 412bcc5b2afcc965a6c8e6d09c3bda62df39bcc5 Merge: 454bdb22e 2cdc6b200 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Apr 10 11:31:33 2019 -0400 Merge remote-tracking branch 'tor-github/pr/926' into maint-0.4.0 changes/bug30040 | 9 +++++++++ src/ext/getdelim.c | 3 ++- 2 files changed, 11 insertions(+), 1 deletion(-)

1 0

[tor/master] Add changes file for #30040.
by nickm＠torproject.org 10 Apr '19

10 Apr '19

commit 2cdc6b2005d2ad09b44cf9a455a70f258e7f6fca Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue Apr 9 17:30:14 2019 +0300 Add changes file for #30040. --- changes/bug30040 | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/changes/bug30040 b/changes/bug30040 new file mode 100644 index 000000000..7d80528a1 --- /dev/null +++ b/changes/bug30040 @@ -0,0 +1,9 @@ + o Minor bugfixes (security): + - Fix a potential double free bug when reading huge bandwidth files. The + issue is not exploitable in the current Tor network because the + vulnerable code is only reached when directory authorities read bandwidth + files, but bandwidth files come from a trusted source (usually the + authorities themselves). Furthermore, the issue is only exploitable in + rare (non-POSIX) 32-bit architectures which are not used by any of the + current authorities. Fixes bug 30040; bugfix on 0.3.5.1-alpha. Bug found + and fixed by Tobias Stoeckmann.

1 0

[tor/master] Prevent double free on huge files with 32 bit.
by nickm＠torproject.org 10 Apr '19

10 Apr '19

commit 9ce0bdd22636a332399d65f280915e899a24b69b Author: Tobias Stoeckmann <tobias(a)stoeckmann.org> Date: Sun Mar 31 12:27:55 2019 +0200 Prevent double free on huge files with 32 bit. The function compat_getdelim_ is used for tor_getline if tor is compiled on a system that lacks getline and getdelim. These systems should be very rare, considering that getdelim is POSIX. If this system is further a 32 bit architecture, it is possible to trigger a double free with huge files. If bufsiz has been already increased to 2 GB, the next chunk would be 4 GB in size, which wraps around to 0 due to 32 bit limitations. A realloc(*buf, 0) could be imagined as "free(*buf); return malloc(0);" which therefore could return NULL. The code in question considers that an error, but will keep the value of *buf pointing to already freed memory. The caller of tor_getline() would free the pointer again, therefore leading to a double free. This code can only be triggered in dirserv_read_measured_bandwidths with a huge measured bandwith list file on a system that actually allows to reach 2 GB of space through realloc. It is not possible to trigger this on Linux with glibc or other major *BSD systems even on unit tests, because these systems cannot reach so much memory due to memory fragmentation. This patch is effectively based on the penetration test report of cure53 for curl available at https://cure53.de/pentest-report_curl.pdf and explained under section "CRL-01-007 Double-free in aprintf() via unsafe size_t multiplication (Medium)". --- src/ext/getdelim.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/ext/getdelim.c b/src/ext/getdelim.c index 8254103ff..1c29baffd 100644 --- a/src/ext/getdelim.c +++ b/src/ext/getdelim.c @@ -67,7 +67,8 @@ compat_getdelim_(char **buf, size_t *bufsiz, int delimiter, FILE *fp) char *nbuf; size_t nbufsiz = *bufsiz * 2; ssize_t d = ptr - *buf; - if ((nbuf = raw_realloc(*buf, nbufsiz)) == NULL) + if (nbufsiz < *bufsiz || + (nbuf = raw_realloc(*buf, nbufsiz)) == NULL) return -1; *buf = nbuf; *bufsiz = nbufsiz;

1 0

[tor/maint-0.4.0] Prevent double free on huge files with 32 bit.
by nickm＠torproject.org 10 Apr '19

10 Apr '19

commit 9ce0bdd22636a332399d65f280915e899a24b69b Author: Tobias Stoeckmann <tobias(a)stoeckmann.org> Date: Sun Mar 31 12:27:55 2019 +0200 Prevent double free on huge files with 32 bit. The function compat_getdelim_ is used for tor_getline if tor is compiled on a system that lacks getline and getdelim. These systems should be very rare, considering that getdelim is POSIX. If this system is further a 32 bit architecture, it is possible to trigger a double free with huge files. If bufsiz has been already increased to 2 GB, the next chunk would be 4 GB in size, which wraps around to 0 due to 32 bit limitations. A realloc(*buf, 0) could be imagined as "free(*buf); return malloc(0);" which therefore could return NULL. The code in question considers that an error, but will keep the value of *buf pointing to already freed memory. The caller of tor_getline() would free the pointer again, therefore leading to a double free. This code can only be triggered in dirserv_read_measured_bandwidths with a huge measured bandwith list file on a system that actually allows to reach 2 GB of space through realloc. It is not possible to trigger this on Linux with glibc or other major *BSD systems even on unit tests, because these systems cannot reach so much memory due to memory fragmentation. This patch is effectively based on the penetration test report of cure53 for curl available at https://cure53.de/pentest-report_curl.pdf and explained under section "CRL-01-007 Double-free in aprintf() via unsafe size_t multiplication (Medium)". --- src/ext/getdelim.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/ext/getdelim.c b/src/ext/getdelim.c index 8254103ff..1c29baffd 100644 --- a/src/ext/getdelim.c +++ b/src/ext/getdelim.c @@ -67,7 +67,8 @@ compat_getdelim_(char **buf, size_t *bufsiz, int delimiter, FILE *fp) char *nbuf; size_t nbufsiz = *bufsiz * 2; ssize_t d = ptr - *buf; - if ((nbuf = raw_realloc(*buf, nbufsiz)) == NULL) + if (nbufsiz < *bufsiz || + (nbuf = raw_realloc(*buf, nbufsiz)) == NULL) return -1; *buf = nbuf; *bufsiz = nbufsiz;

1 0

[tor/release-0.4.0] Add changes file for #30040.
by nickm＠torproject.org 10 Apr '19

10 Apr '19

commit 2cdc6b2005d2ad09b44cf9a455a70f258e7f6fca Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue Apr 9 17:30:14 2019 +0300 Add changes file for #30040. --- changes/bug30040 | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/changes/bug30040 b/changes/bug30040 new file mode 100644 index 000000000..7d80528a1 --- /dev/null +++ b/changes/bug30040 @@ -0,0 +1,9 @@ + o Minor bugfixes (security): + - Fix a potential double free bug when reading huge bandwidth files. The + issue is not exploitable in the current Tor network because the + vulnerable code is only reached when directory authorities read bandwidth + files, but bandwidth files come from a trusted source (usually the + authorities themselves). Furthermore, the issue is only exploitable in + rare (non-POSIX) 32-bit architectures which are not used by any of the + current authorities. Fixes bug 30040; bugfix on 0.3.5.1-alpha. Bug found + and fixed by Tobias Stoeckmann.

1 0

[tor/master] Merge branch 'maint-0.4.0'
by nickm＠torproject.org 10 Apr '19

10 Apr '19

commit 3be1e26b8d27b9baa89549fff56fadd2894ec00f Merge: 60c46c6cd 412bcc5b2 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Apr 10 11:31:44 2019 -0400 Merge branch 'maint-0.4.0' changes/bug30040 | 9 +++++++++ src/ext/getdelim.c | 3 ++- 2 files changed, 11 insertions(+), 1 deletion(-)

1 0

[tor/release-0.4.0] Prevent double free on huge files with 32 bit.
by nickm＠torproject.org 10 Apr '19

10 Apr '19

commit 9ce0bdd22636a332399d65f280915e899a24b69b Author: Tobias Stoeckmann <tobias(a)stoeckmann.org> Date: Sun Mar 31 12:27:55 2019 +0200 Prevent double free on huge files with 32 bit. The function compat_getdelim_ is used for tor_getline if tor is compiled on a system that lacks getline and getdelim. These systems should be very rare, considering that getdelim is POSIX. If this system is further a 32 bit architecture, it is possible to trigger a double free with huge files. If bufsiz has been already increased to 2 GB, the next chunk would be 4 GB in size, which wraps around to 0 due to 32 bit limitations. A realloc(*buf, 0) could be imagined as "free(*buf); return malloc(0);" which therefore could return NULL. The code in question considers that an error, but will keep the value of *buf pointing to already freed memory. The caller of tor_getline() would free the pointer again, therefore leading to a double free. This code can only be triggered in dirserv_read_measured_bandwidths with a huge measured bandwith list file on a system that actually allows to reach 2 GB of space through realloc. It is not possible to trigger this on Linux with glibc or other major *BSD systems even on unit tests, because these systems cannot reach so much memory due to memory fragmentation. This patch is effectively based on the penetration test report of cure53 for curl available at https://cure53.de/pentest-report_curl.pdf and explained under section "CRL-01-007 Double-free in aprintf() via unsafe size_t multiplication (Medium)". --- src/ext/getdelim.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/ext/getdelim.c b/src/ext/getdelim.c index 8254103ff..1c29baffd 100644 --- a/src/ext/getdelim.c +++ b/src/ext/getdelim.c @@ -67,7 +67,8 @@ compat_getdelim_(char **buf, size_t *bufsiz, int delimiter, FILE *fp) char *nbuf; size_t nbufsiz = *bufsiz * 2; ssize_t d = ptr - *buf; - if ((nbuf = raw_realloc(*buf, nbufsiz)) == NULL) + if (nbufsiz < *bufsiz || + (nbuf = raw_realloc(*buf, nbufsiz)) == NULL) return -1; *buf = nbuf; *bufsiz = nbufsiz;

1 0