diff options
| author | Nick Mathewson <nickm@torproject.org> | 2017-04-07 10:47:16 -0400 |
|---|---|---|
| committer | Nick Mathewson <nickm@torproject.org> | 2017-04-07 10:47:16 -0400 |
| commit | 4812441d3465f4f2fc6763ee644f79d5a9c8661b (patch) | |
| tree | 6a6f9b7d7325b7b68ba39b8ac54f556ec1d0285d /changes/bug21894_029 | |
| parent | 7d7770f7359763871667e0150aebc50856f9d5fd (diff) | |
| download | tor-4812441d3465f4f2fc6763ee644f79d5a9c8661b.tar.gz tor-4812441d3465f4f2fc6763ee644f79d5a9c8661b.zip | |
Never read off the end of a buffer in base32_encode()
When we "fixed" #18280 in 4e4a7d2b0c199227252a742541461ec4cc35d358
in 0291 it appears that we introduced a bug: The base32_encode
function can read off the end of the input buffer, if the input
buffer size modulo 5 is not equal to 0 or 3.
This is not completely horrible, for two reasons:
* The extra bits that are read are never actually used: so this
is only a crash when asan is enabled, in the worst case. Not a
data leak.
* The input sizes passed to base32_encode are only ever multiples
of 5. They are all either DIGEST_LEN (20), REND_SERVICE_ID_LEN
(10), sizeof(rand_bytes) in addressmap.c (10), or an input in
crypto.c that is forced to a multiple of 5.
So this bug can't actually trigger in today's Tor.
Closes bug 21894; bugfix on 0.2.9.1-alpha.
Diffstat (limited to 'changes/bug21894_029')
| -rw-r--r-- | changes/bug21894_029 | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/changes/bug21894_029 b/changes/bug21894_029 new file mode 100644 index 0000000000..e3a84fa721 --- /dev/null +++ b/changes/bug21894_029 @@ -0,0 +1,5 @@ + o Minor bugfixes (crash prevention): + - Fix an (currently untriggerable, but potentially dangerous) crash + bug when base32-encoding inputs whose sizes are not a multiple of + 5. Fixes bug 21894; bugfix on 0.2.9.1-alpha. + |