aboutsummaryrefslogtreecommitdiff
path: root/changes/bug7352
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2012-11-07 16:09:58 -0500
committerNick Mathewson <nickm@torproject.org>2012-11-08 16:44:50 -0500
commit49dd5ef3a3d1775fdc3c0a7d069d3097b3baeeec (patch)
tree7189ed200ae8f47bf7d3399d0b99243dc93bced3 /changes/bug7352
parent758428dd32128874cefacc92ef63c1b5bc9a656e (diff)
downloadtor-49dd5ef3a3d1775fdc3c0a7d069d3097b3baeeec.tar
tor-49dd5ef3a3d1775fdc3c0a7d069d3097b3baeeec.tar.gz
Add and use and unlikely-to-be-eliminated memwipe()
Apparently some compilers like to eliminate memset() operations on data that's about to go out-of-scope. I've gone with the safest possible replacement, which might be a bit slow. I don't think this is critical path in any way that will affect performance, but if it is, we can work on that in 0.2.4. Fixes bug 7352.
Diffstat (limited to 'changes/bug7352')
-rw-r--r--changes/bug735212
1 files changed, 12 insertions, 0 deletions
diff --git a/changes/bug7352 b/changes/bug7352
new file mode 100644
index 000000000..74a878dbe
--- /dev/null
+++ b/changes/bug7352
@@ -0,0 +1,12 @@
+ o Major bugfixes:
+ - Tor tries to wipe potentially sensitive data after using it, so
+ that if some subsequent security failure exposes Tor's memory,
+ the damage will be limited. But we had a bug where the compiler
+ was eliminating these wipe operations when it decided that the
+ memory was no longer visible to a (correctly running) program,
+ hence defeating our attempt at defense in depth. We fix that
+ by using OpenSSL's OPENSSL_cleanse() operation, which a compiler
+ is unlikely to optimize away. Future versions of Tor may use
+ a less ridiculously heavy approach for this. Fixes bug 7352.
+ Reported in an article by Andrey Karpov.
+