Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:43:04Zhttps://gitlab.torproject.org/legacy/trac/-/issues/31001Undefined behavior in tor_vasprintf()2020-06-13T15:43:04ZGeorge KadianakisUndefined behavior in tor_vasprintf()```
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 re...```
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<in total 2147483610 As>
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.
```Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30614Use MAP_INHERIT_NONE/ZERO if available instead of crashing on assertion failure2020-06-13T15:41:42ZriastradhUse MAP_INHERIT_NONE/ZERO if available instead of crashing on assertion failureOn NetBSD, the way to ask a page range be zero'd or unmapped on fork is `minherit(addr, nbytes, MAP_INHERIT_ZERO)` or `minherit(addr, nbytes, MAP_INHERIT_NONE)`. However,
- map_anon.c does not actually check for or use `MAP_INHERIT_ZER...On NetBSD, the way to ask a page range be zero'd or unmapped on fork is `minherit(addr, nbytes, MAP_INHERIT_ZERO)` or `minherit(addr, nbytes, MAP_INHERIT_NONE)`. However,
- map_anon.c does not actually check for or use `MAP_INHERIT_ZERO` or `MAP_INHERIT_NONE`, so
- `FLAG_NOINHERIT` is undefined, so
- `tor_mmap_anonymous` fails to disinherit the mapping, so
- `crypto_fast_rng_new_from_seed` throws a fit.
```
slow/prob_distr/stochastic_log_logistic: [forking] May 25 03:56:58.091 [err] tor_assertion_failed_(): Bug: src/lib/crypt_ops/crypto_rand_fast.c:184: crypto_fast_rng_new_from_seed: Assertion inherit != INHERIT_RES_KEEP failed; aborting. (on Tor 0.4.1.1-alpha-dev 29955f13e5bc8e61)
May 25 03:56:58.091 [err] Bug: Assertion inherit != INHERIT_RES_KEEP failed in crypto_fast_rng_new_from_seed at src/lib/crypt_ops/crypto_rand_fast.c:184: . (Stack trace not available) (on Tor 0.4.1.1-alpha-dev 29955f13e5bc8e61)
[Lost connection!]
```
The attached patch checks for and uses `MAP_INHERIT_ZERO` and `MAP_INHERIT_NONE`. **However, it does not adjust the code path that gets confused if `tor_mmap_anonymous` fails to disinherit the mapping,** which might be worth doing too, perhaps earlier on by detecting and noisily reporting a lack of support for cutting off the hereditary concentration of wealth, or at least secrets, in society before it's too late.Tor: 0.4.0.x-final