Wipe relay key material from memory on common crash conditions

Tor should wipe key material before common crash conditions, to avoid key material leak in the case where relay operators have otherwise taken steps to keep key material off of disk.

There are two vectors towards obtaining key material after crash: core files, and large mmap attempts by other users' processes.

It turns out many OS kernels do not provide ways to defend against the latter case. Therefore, tor should attempt to wipe sensitive key material on atexit, SIGSEGV, SIGBUS, tor_assert() and other common exit conditions.

changed milestone to %Tor: unspecified

added component::core tor/tor hardening intro memwipe milestone::Tor: unspecified parent::5456 points::5 priority::high severity::normal small-feature status::new tor-relay type::enhancement labels

Related is #7005 (moved) - if we ever trigger a seccomp2 failure - we'd want to execute such a panic button.

Clarification: This ticket is for wiping key material from memory, not disk. The presumption is that the keys have already been removed from disk (and possibly stored offsite) manually by the relay admin.

Not storing keys on disk in the first place and other forms of relay key agility should be considered in separate tickets, as they are more involved than this specific issue.

Trac:
Summary: Wipe relay keys on common crash conditions to Wipe relay key material from memory on common crash conditions

I've heard worse ideas. I'd want the code here to be absolutely bulletproof, and to get invoked as part of our regular shutdown logic (so that it would see some testing).

This "common crash conditions" idea is one where I'd like to see what you have in mind enumerated.

We might need to ignore Libevent's regular signal logic, since it isn't meant for signals that have put an unknown portion of the process into a non-runnable state.

Trac:
Keywords: MikePerry201212, small-feature deleted, MikePerry201212 small-feature tor-relay added

Trac:
Component: Tor Relay to Tor

Trac:
Keywords: MikePerry201212 small-feature tor-relay deleted, small-feature tor-relay added

No code at this point means it turns into an 0.2.5 feature.

Trac:
Milestone: Tor: 0.2.4.x-final to Tor: 0.2.5.x-final

Trac:
Milestone: Tor: 0.2.5.x-final to Tor: 0.2.???

Trac:
Keywords: small-feature tor-relay deleted, small-feature, intro, tor-relay added

Trac:
Points: N/A to medium
Severity: N/A to Normal
Sponsor: N/A to N/A

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

Trac:
Milestone: Tor: 0.3.??? to Tor: unspecified
Keywords: N/A deleted, tor-03-unspecified-201612 added

How much sensitive material is there? Just a shot in the dark, but perhaps the material could be encrypted in order to keep the amount of time it's decrypted very short, so all it takes is wiping the master key from memory to make the rest of the encrypted sensitive material in memory unreadable. When the process is in an undefined state (according to POSIX, SIGSEGV not induced by raise(3) or kill(2) puts a process in such a state), it would be much easier for it to wipe a single page than it would be to find and wipe a time-varying amount of memory in multiple locations.

Trac:
Reviewer: N/A to N/A

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Points: medium to 5
Keywords: intro deleted, intro hardening memwipe added

What key material is being considered as sensitive here? Is it only private keys, or does it also include ephemeral session keys and related information? It's important to determine what's in scope.

Also, coredumps do not have to be an issue if Tor sets prctl(PR_SET_DUMPABLE, 0).

changed time estimate to 40h

moved to tpo/core/tor#7003 (closed)