Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reboot every 24 hours to periodically wipe memory #805

Merged
merged 1 commit into from Dec 16, 2014

Conversation

Projects
None yet
3 participants
@garrettr
Copy link
Contributor

commented Dec 13, 2014

This is a kludge, but a reasonably effective one. This change reboots
the servers every day at 5am. Previously this reboot would only happen
if required by the daily package upgrade (e.g. for a kernel upgrade),
but now it happens every day regardless of whether it is needed.

This ensures that the plaintext of submissions can reside in memory for
at most 24 hours after submission. Resolves #99, although we can and
should do better in a future release.

Reboot every 24 hours to periodically wipe memory
This is a kludge, but a reasonably effective one. This change reboots
the servers every day at 5am. Previously this reboot would only happen
if required by the daily package upgrade (e.g. for a kernel upgrade),
but now it happens every day regardless of whether it is needed.

This ensures that the plaintext of submissions can reside in memory for
at most 24 hours after submission. Resolves #99, although we can and
should do better in a future release.
@dolanjs

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2014

lgtm

garrettr added a commit that referenced this pull request Dec 16, 2014

Merge pull request #805 from freedomofpress/minimize-plaintext-retent…
…ion-with-reboot

Reboot every 24 hours to periodically wipe memory

@garrettr garrettr merged commit 6f4bc2f into develop Dec 16, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details

darkk added a commit to darkk/securedrop that referenced this pull request Oct 20, 2015

garrettr added a commit that referenced this pull request Oct 20, 2015

Merge pull request #1154 from darkk/patch-1
Fix PR #805 link in thread_model.md
@nvesely

This comment has been minimized.

Copy link
Contributor

commented Oct 22, 2015

I'm going to quote some text from the 2008 paper "Lest We Remember: Cold Boot Attacks on Encryption Keys." Though the paper is focused on the extraction of encryption keys from DRAMs, much of the information relates to exploiting DRAM remenance effects, which could apply to any data.

A DRAM cell is essentially a capacitor. Each cell encodes a single bit by either charging or not charging one of the capacitor’s conductors. The other conductor is hard-wired either to power or to ground, depending on the cell’s address within the chip [37,23].

Over time, charge will leak out of the capacitor, and the cell will lose its state or, more precisely, it will decay to its groundstate, either zero or one depending on whether the fixed conductor of the capacitor is hard-wired to ground or power. To forestall this decay, the cell must be refreshed, meaning that the capacitor must be re-charged to hold its value. Specifications for DRAM chips give a refresh time , which is the maximum interval that is supposed to pass before a cell is refreshed. The standard refresh time (usually on the order of milliseconds) is meant to achieve extremely high reliability for normal computer operations where even infrequent bit errors could cause serious prob- lems; however, a failure to refresh any individual DRAM cell within this time has only a tiny probability of actually destroying the cell’s contents

[...]

We found that machines using newer memory technologies tend to exhibit a shorter time to total decay than machines using older memory technologies, but even the shorter times are long enough to facilitate most of our attacks. We as- cribe this trend to the increasing density of the DRAM cells as the technology improves; in general, memory with higher densities have a shorter window where data is recoverable. While this trend might make DRAM re- tention attacks more difficult in the future, manufacturers also generally seek to increase retention times, because DRAMs with long retention require less frequent refresh and have lower power consumption.

[...]

In the systems we tested, the BIOS overwrote only relatively small fractions of memory with its own code and data, typically a few megabytes concentrated around the bottom of the address space.

On many machines, the BIOS can perform a destructive memory check during its Power-On Self Test (POST). Most of the machines we examined allowed this test to be disabled or bypassed (sometimes by enabling an option called “Quick Boot”).

On other machines, mainly high-end desktops and servers that support ECC memory, we found that the BIOS cleared memory contents without any override op- tion. ECC memory must be set to a known state to avoid spurious errors if memory is read without being initial- ized [ 6 ], and we believe many ECC-capable systems per- form this wiping operation whether or not ECC memory is installed.

[...]

Imaging residual memory contents requires no special equipment. When the system boots, the memory con- troller begins refreshing the DRAM, reading and rewriting each bit value. At this point, the values are fixed, decay halts, and programs running on the system can read any data present using normal memory-access instructions.

[...]

A warm boot, invoked with the operating system’s restart procedure, will normally ensure that the memory has no chance to decay, though software will have an opportunity to wipe sensitive data prior to shutdown.

Basically restating this, it seems that we can conclude that if the App Server has ECC memory or it is set to run a POST on boot, a warm reboot should be completely successful at clearing plaintext data from RAM. If it is compatible w/ ECC memory, a warm reboot may also be sufficient. However, if the App Server is neither ECC RAM compatible, nor does it run a POST on boot, plaintexts may persist through warm reboots.

The Intel D54250WYK you recommend does not support ECC memory, so if you want this kludge to be effective with that machine you should suggest enabling running POST on every startup.

@garrettr

This comment has been minimized.

Copy link
Contributor Author

commented Oct 22, 2015

@fowlslegs Good point, thanks for drawing out the relevant details from the cold boot paper. I was aware of those results - my reasoning here is not that a reboot can be used to decay memory, but that the shutdown will cause all processes to terminate (init sends SIGTERM to all processes), and PAX_MEMORY_SANITIZE will sanitize them as they go.

Of course, I should've explained this in the original comment on the PR. I also haven't tested this on hardware, although that would probably be worthwhile and would definitely be fun!

@nvesely

This comment has been minimized.

Copy link
Contributor

commented Sep 26, 2016

Maybe I'm missing something here, but why is it not enough to just restart Apache? Are there processes besides the WSGI app and Apache that buffer the submissions in memory?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.