Hacker News Reader

Comment by l33t233372 | Hacker News Reader

I don’t understand why this would help prevent cold boot attacks.

Wouldn’t the memory need to bee free’d first for this to have any effect?

Yes it would - either through the free syscall or a process exit. This is a defense in depth strategy and not 100% perfect. If you yanked the power cord and a long lived process had sensitive data in memory you're still vulnerable. But if you had a clean power down or very short lifetimes of sensitive data being active in RAM it would afford you additional security.

?? Cutting the power means the RAM contents vanish.

They vanish eventually which is usually measured in seconds. This can be extended to minutes or hours if someone performs a cold boot attack: https://security.stackexchange.com/questions/10643/recover-t...

I find that phrasing weird.

A cold boot attack relies on a cold boot of the system to evade kernel protections(as opposed to a warm boot where the kernel can zero memory.)

The name has nothing to do with reducing the temperature of the ram to extend the time it takes bytes to vanish in ram.

I think it’s a little bit of column A and a little bit of column B, but admit while I remember reading about using technique a long time ago, I’m not sure of the history of the nomenclature. From the StackExchange:

> For those who think this is only theoretical: They were able to use this technique to create a bootable USB device which could determine someone's Truecrypt hard-drive encryption key automatically, just by plugging it in and restarting the computer. They were also able to recover the memory-contents 30 minutes+ later by freezing the ram (using a simple bottle of canned-air) and removing it. Using liquid nitrogen increased this time to hours.

Reducing the temperature of the RAM can be done to make a cold boot attack easier, but it’s not the origin of the name.

For more details, see the paper Lest We Remember.

Thanks, TIL! I'll check it out.

i didn't know that. Thanks!

the idea is that well written software would release memory as soon as possible so with it enabled you'd have the secret in memory for as little time as possible.

Though in my mind well written software should be zeroing the memory out before freeing if it held sensitive data.

Yes I thought that was common practice - I remember reading patch notes for something years ago where the program had been updated to always zero the password buffer after checking that it matches (I think in some cases it was kept around for a bit).

From a defense in depth perspective you definitely want the implementation to be robust (zero the memory after reading). However you should also consider:

1) abnormal program termination due to signals, memory pressure/oom killer, aborts in other threads serving different requests, and so on. These events could race with the memory zeroing.

2) bugs in the implementation where memory isn't zeroed in all paths

3) interactions between compiling, standard libraries, language runtimes and optimization passes causing memory zeroing to be skipped.

All these cases have happened time and time again in the wild. Hence having additional safety nets is useful.

These patches were endorsed by folks working on chromeos and Android security. I would suppose that they want them to put additional safeguards behind full disk encryption keys and may also be concerned with quality of implementation issues in 3rd party or vendor blobs.

Reply on news.ycombinator.com