diff options
| author | Nick Mathewson <nickm@torproject.org> | 2012-11-07 16:09:58 -0500 |
|---|---|---|
| committer | Nick Mathewson <nickm@torproject.org> | 2012-11-08 16:44:50 -0500 |
| commit | 49dd5ef3a3d1775fdc3c0a7d069d3097b3baeeec (patch) | |
| tree | 7189ed200ae8f47bf7d3399d0b99243dc93bced3 /changes/bug7352 | |
| parent | 758428dd32128874cefacc92ef63c1b5bc9a656e (diff) | |
| download | tor-49dd5ef3a3d1775fdc3c0a7d069d3097b3baeeec.tar.gz tor-49dd5ef3a3d1775fdc3c0a7d069d3097b3baeeec.zip | |
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/bug7352 | 12 |
1 files changed, 12 insertions, 0 deletions
diff --git a/changes/bug7352 b/changes/bug7352 new file mode 100644 index 0000000000..74a878dbe0 --- /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. + |