From 0d4a689d3ae8f7e05b3baf8ad71d983a767ef55b Mon Sep 17 00:00:00 2001 From: Tobias Stoeckmann Date: Mon, 24 Jun 2019 22:08:49 +0200 Subject: [PATCH 1/4] Prevent UB on signed overflow. Overflowing a signed integer in C is an undefined behaviour. It is possible to trigger this undefined behaviour in tor_asprintf on Windows or systems lacking vasprintf. On these systems, eiter _vscprintf or vsnprintf is called to retrieve the required amount of bytes to hold the string. These functions can return INT_MAX. The easiest way to recreate this is the use of a specially crafted configuration file, e.g. containing the line: FirewallPorts AAAAA This line triggers the needed tor_asprintf call which eventually leads to an INT_MAX return value from _vscprintf or vsnprintf. The needed byte for \0 is added to the result, triggering the overflow and therefore the undefined behaviour. Casting the value to size_t before addition fixes the behaviour. Signed-off-by: Tobias Stoeckmann --- src/common/compat.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/src/common/compat.c b/src/common/compat.c index 9758751122..6f7ac7bd7d 100644 --- a/src/common/compat.c +++ b/src/common/compat.c @@ -540,8 +540,8 @@ tor_vasprintf(char **strp, const char *fmt, va_list args) *strp = NULL; return -1; } - strp_tmp = tor_malloc(len + 1); - r = _vsnprintf(strp_tmp, len+1, fmt, args); + strp_tmp = tor_malloc((size_t)len + 1); + r = _vsnprintf(strp_tmp, (size_t)len+1, fmt, args); if (r != len) { tor_free(strp_tmp); *strp = NULL; @@ -566,9 +566,9 @@ tor_vasprintf(char **strp, const char *fmt, va_list args) *strp = tor_strdup(buf); return len; } - strp_tmp = tor_malloc(len+1); + strp_tmp = tor_malloc((size_t)len+1); /* use of tor_vsnprintf() will ensure string is null terminated */ - r = tor_vsnprintf(strp_tmp, len+1, fmt, args); + r = tor_vsnprintf(strp_tmp, (size_t)len+1, fmt, args); if (r != len) { tor_free(strp_tmp); *strp = NULL; @@ -3543,4 +3543,3 @@ tor_get_avail_disk_space(const char *path) return -1; #endif } - From 97d73db7c36ec3fac2974726012f76bff63f9dfc Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Fri, 19 Jul 2019 09:21:08 -0400 Subject: [PATCH 2/4] Changes file for bug 31001 --- changes/ticket31001 | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 changes/ticket31001 diff --git a/changes/ticket31001 b/changes/ticket31001 new file mode 100644 index 0000000000..2ce1cbdf34 --- /dev/null +++ b/changes/ticket31001 @@ -0,0 +1,6 @@ + o Minor bugfixes (compatibility, standards compliance): + - Fix a bug that would invoke undefined behavior on certain operating + systems when trying to asprintf() a string exactly INT_MAX bytes + long. We don't believe this is exploitable, but it's better + to fix it anyway. Fixes bug 31001; bugfix on 0.2.2.11-alpha. + Found and fixed by Tobias Stoeckmann. From 4233fb7014b0ef5a6830f36608e1779299e07cd8 Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Wed, 16 Oct 2019 06:13:14 -0400 Subject: [PATCH 3/4] clarify in man page: we count by powers of two Make clear in the man page, in both the bandwidth section and the accountingmax section, that Tor counts in powers of two, not powers of ten: 1 GByte is 1024*1024*1024 bytes, not one billion bytes. Resolves ticket 32106. --- changes/bug32106 | 5 +++++ doc/tor.1.txt | 17 +++++++++++++---- 2 files changed, 18 insertions(+), 4 deletions(-) create mode 100644 changes/bug32106 diff --git a/changes/bug32106 b/changes/bug32106 new file mode 100644 index 0000000000..c6e8e95860 --- /dev/null +++ b/changes/bug32106 @@ -0,0 +1,5 @@ + o Minor features (documentation): + - Make clear in the man page, in both the bandwidth section and the + accountingmax section, that Tor counts in powers of two, not + powers of ten: 1 GByte is 1024*1024*1024 bytes, not one billion + bytes. Resolves ticket 32106. diff --git a/doc/tor.1.txt b/doc/tor.1.txt index 6b81e19ba1..be0a1ed928 100644 --- a/doc/tor.1.txt +++ b/doc/tor.1.txt @@ -210,11 +210,15 @@ GENERAL OPTIONS + Note that this option, and other bandwidth-limiting options, apply to TCP data only: They do not count TCP headers or DNS traffic. + + + + Tor uses powers of two, not powers of ten, so 1 GByte is + 1024*1024*1024 bytes as opposed to 1 billion bytes. + + With this option, and in other options that take arguments in bytes, KBytes, and so on, other formats are also supported. Notably, "KBytes" can also be written as "kilobytes" or "kb"; "MBytes" can be written as "megabytes" or "MB"; "kbits" can be written as "kilobits"; and so forth. + Case doesn't matter. Tor also accepts "byte" and "bit" in the singular. The prefixes "tera" and "T" are also recognized. If no units are given, we default to bytes. @@ -2292,9 +2296,9 @@ is non-zero): using a given calculation rule (see: AccountingStart, AccountingRule). Useful if you need to stay under a specific bandwidth. By default, the number used for calculation is the max of either the bytes sent or - received. For example, with AccountingMax set to 1 GByte, a server - could send 900 MBytes and receive 800 MBytes and continue running. - It will only hibernate once one of the two reaches 1 GByte. This can + received. For example, with AccountingMax set to 1 TByte, a server + could send 900 GBytes and receive 800 GBytes and continue running. + It will only hibernate once one of the two reaches 1 TByte. This can be changed to use the sum of the both bytes received and sent by setting the AccountingRule option to "sum" (total bandwidth in/out). When the number of bytes remaining gets low, Tor will stop accepting new connections @@ -2305,7 +2309,12 @@ is non-zero): enabling hibernation is preferable to setting a low bandwidth, since it provides users with a collection of fast servers that are up some of the time, which is more useful than a set of slow servers that are - always "available". + always "available". + + + + Note that (as also described in the Bandwidth section) Tor uses + powers of two, not powers of ten: 1 GByte is 1024*1024*1024, not + one billion. Be careful: some internet service providers might count + GBytes differently. [[AccountingRule]] **AccountingRule** **sum**|**max**|**in**|**out**:: How we determine when our AccountingMax has been reached (when we From 80a198928e14f5932f283206541124209df95fb7 Mon Sep 17 00:00:00 2001 From: Philipp Winter Date: Thu, 19 Sep 2019 12:42:44 -0700 Subject: [PATCH 4/4] Remove outdated note. BridgeDB supports bridge-distribution lines since version 0.5.0: --- doc/tor.1.txt | 4 ---- 1 file changed, 4 deletions(-) diff --git a/doc/tor.1.txt b/doc/tor.1.txt index be0a1ed928..1504223b89 100644 --- a/doc/tor.1.txt +++ b/doc/tor.1.txt @@ -1956,10 +1956,6 @@ is non-zero): would like its bridge address to be given out. Set it to "none" if you want BridgeDB to avoid distributing your bridge address, or "any" to let BridgeDB decide. (Default: any) - + - Note: as of Oct 2017, the BridgeDB part of this option is not yet - implemented. Until BridgeDB is updated to obey this option, your - bridge will make this request, but it will not (yet) be obeyed. [[ContactInfo]] **ContactInfo** __email_address__:: Administrative contact information for this relay or bridge. This line