|
|
**Should I use --enable-expensive-hardening?**
|
|
|
|
|
|
Does "expensive-hardening" makes your Tor more secure or less secure? The answer isn't obvious!
|
|
|
|
|
|
The 'expensive-hardening' option replaces a number of underlying bugs with aborts. If any of these underlying bugs was remotely triggerable, it becomes a remotely triggerable abort.
|
|
|
|
|
|
Some possible underlying bugs here are actually harmless -- like the integer underflow bug here in TROVE-2017-001, or the read-one-extra-byte bug of TROVE-2016-12-002[*]. So long as any bugs like these bugs exist, "expensive-hardening" will make your Tor more vulnerable to remote denial of service.
|
|
|
|
|
|
But some possible underlying bugs are potential trouble -- like if we had an actual stack overflow bug or a heap overflow bug. "expensive-hardening" can replace some of these with aborts too. So long as any bugs like these bugs exist, "expensive-hardening" makes it a little more difficult to do RCE or heartbleed-style leaks against your Tor.
|
|
|
|
|
|
The first kind of bug seems much more common in practice over Tor's history. But the impact of the second kind would be significantly worse.
|
|
|
|
|
|
So using "expensive-hardening" in production means "Make me much more vulnerable to remote DoS, but (probably) less vulnerable to RCE or heartbleed."
|
|
|
|
|
|
I don't think that's an obvious "yes", but I'm also not totally sure it's an obvious "no". |
|
|
\ No newline at end of file |