Opened 8 years ago

Last modified 2 years ago

#7003 new enhancement

Wipe relay key material from memory on common crash conditions

Reported by: mikeperry Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: small-feature, tor-relay, intro hardening memwipe
Cc: ioerror, nickm Actual Points:
Parent ID: #5456 Points: 5
Reviewer: Sponsor:


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.

Child Tickets

Change History (16)

comment:1 Changed 8 years ago by ioerror

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

comment:2 Changed 8 years ago by mikeperry

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

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.

comment:3 Changed 8 years ago by nickm

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.

comment:4 Changed 8 years ago by nickm

Keywords: tor-relay added

comment:5 Changed 8 years ago by nickm

Component: Tor RelayTor

comment:6 Changed 7 years ago by mikeperry

Keywords: MikePerry201212 removed

comment:7 Changed 7 years ago by arma

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

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

comment:8 Changed 6 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:9 Changed 4 years ago by nickm

Keywords: intro added

comment:10 Changed 4 years ago by nickm

Points: medium
Severity: Normal

comment:11 Changed 4 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:12 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

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

comment:13 Changed 3 years ago by cypherpunks

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.

comment:14 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:15 Changed 3 years ago by nickm

Keywords: hardening memwipe added
Points: medium5

comment:16 Changed 2 years ago by cypherpunks

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).

Note: See TracTickets for help on using tickets.