Is RAM Wipe possible inside Whonix? Cold Boot Attack Defense

Does RAM decay on notebooks where most of the time the power is plugged in a battery available?

If a cold boot attack might be a problem, then make sure that
A) the power get’s turned off automatically without user intervention after a couple of seconds. Think of a “dead man’s switch”
and
B) it takes time to get to the RAM modules. Screw all the screws on your PC case and make sure the user needs a screwdriver before being able to unscrew them. Many high-end PC cases are shipped with screws that can be unscrewed manually without a screwdriver. In this case it might make sense to replace them with normal screws.
The longer an attacker needs to get access to the RAM modules, the better it is.

Now about the RAM.
Some single board computer do not use DDR3 or DDR4 RAM.
This should be kept in mind if someone is planing to use Whonix on them.

I am not sure about that, but i would assume that the data in the RAM does decay, when the user does not use suspend to RAM when turning it off.
Otherwise the battery would run out of energy within days while the NB wasn’t used at all.
Especially DDR RAM is a small energy consumer. If you design a mobile device, you don’t want to have it consume energy when it is turned off.

But it can also be measures.
Just measure the energy requirement when the NB is turned off with the energy requirement when the NB is suspend to RAM.
If it differs, then the data on the RAM should decay.

No, but it’s stated already on the wiki page that the battery should be removed.

That’s true. But I guess everything x86_64 based nowadays has at least DDR3, the RPI3 has soldered DDR2. This makes unplugging the RAM somewhat less convenient but it holds its state for a longer time. It’s only the gateway however which should not log sensitive stuff anyways. Also some of the more recent SBCs use DDR3 or DDR4 and hopefully the next RPI model will too.
Also we then get to the point what to do with multiple devices at the same time. Do you tie the RPI and the PC running the Workstation each to your wrist? Maybe some other running PCs too?
It would (imho) be way better/convenient/(secure?) to just connect all of those to the same power socket and switch them off when needed.

1 Like

Related, and maybe bad news:
Install memlockd by default? (daemon to increase system reliablity during low RAM)

First, most memory is erased at the end of a normal shutdown/reboot sequence. This is implemented by the Linux kernel’s freed memory poisoning feature, more specifically:

  • page_poison
  • passing “P” to slub_debug
  • zeroing heap memory at free time ( init_on_free=1 )

That part was implemented into security-misc during Kernel Hardening - security-misc thanks to @madaidan.

But other parts mentioned there are yet to be ported and packaged. Not a trivial copy/paste task because some parts are Tails / ISO specific.

1 Like

We should advise users in the wiki to properly shutdown so this kicks in rather than forcing a shutdown (i.e. pulling the plug).

hardened-host-kernel also enables CONFIG_RESET_ATTACK_MITIGATION to wipe memory if the firmware supports it.

1 Like

Some documentation on cold boot attack defense is indeed required.

I was wondering to add it here: Full Disk Encryption (FDE) (FDE) - but strictly while it matters a lot for FDE it also matters for non-FDE and use with Live Mode for Kicksecure. Created a stub here and added links to it:

1 Like

In summary: says cannot be implemented using systemd. Should be done by the kernel.

Quote Lennart Poettering:

Uh, we can’t do that from userspace, we don’t even et access to that. This is something that needs to be implemented in the kernel, for example with a magic sysrq thing.

I think this feature requests has merits, but it really needs to be filed against the kernel as a feature request, systemd is not the right place where we could implement that.

Closing this here hence, I hope that makes sense?

Quote Linux Kernel Driver DataBase: CONFIG_RESET_ATTACK_MITIGATION: Reset memory attack mitigation

Request that the firmware clear the contents of RAM after a reboot using the TCG Platform Reset Attack Mitigation specification. This protects against an attacker forcibly rebooting the system while it still contains secrets in RAM, booting another OS and extracting the secrets. This should only be enabled when userland is configured to clear the MemoryOverwriteRequest flag on clean shutdown after secrets have been evicted, since otherwise it will trigger even on clean reboots.

So the kernel has support for RAM wipe when firmware supports it.

Does the kernel also support RAM wipe if the firmware does not support it? If no, worth writing a feature request against the kernel?

1 Like

Apart from init_on_free and so on, no.

No, the firmware is what wipes RAM. The kernel just enables that feature in the firmware. The kernel isn’t able to wipe all of the RAM itself which is why it must be done at a lower level like the firmware or Tails’ magic.

2 Likes

Is it worth porting the Tails magic to Whonix / Kicksecure?

My post is presupposing that one has read this page beforehand:
Tails - Memory erasure

Tails has a test for this:
features/erase_memory.feature · master · tails / tails · GitLab

^ that is a test definition file but pretty cool and human readable.

The test concludes with:

Then I find very few patterns in the guest’s memory

Which means the definition (the actual not so easily readable implementation of that human readable summary in source code) has some acceptance for leftover memory traces. Here it is:
features/erase_memory.feature · master · tails / tails · GitLab

Relevant part:

max_coverage = 0.008

I.e. less then 0.008% of the pattern which the test wrote can be found.

Is this 0.008% important or anything else not covered by the RAM wipe?

See also this for leftovers in RAM that cannot be wiped by Tails implementation:
https://web.archive.org/web/20180628102336/https://mailman.boum.org/pipermail/tails-dev/2017-January/011134.html

Some things such as importantly, full disk encryption (FDE) is handled by the kernel. Probably user space couldn’t wipe the kernel memory holding the FDE key (unless there is a kernel API for that which would be related but separate).

On that view, wiping RAM might make sense for a live system such as Tails or Whonix / Kicksecure Host Live Mode (specifically when not using encrypted persistence) but would it also make sense for an FDE Whonix-Host or FDE Kicksecure-Host?

Without actual memory forensics we would not really know how severe any RAM wipe leftovers would be. If it includes the FDE key, then wiping the rest was worth little.

Even if RAM wipe by Linux kernel without firmware support would not be complete it could still per perfect and it could certainly better than anything doable in user space such as the Tails implementation. The kernel can certainly has the power to wipe any program from RAM since these are below the kernel in the hierarchy. And the kernel would not have to wipe things where the kernel knows that wiping these memory parts is not important because these are public anyhow, not private/secrets, or recoverable from the hard drive (assuming unencrypted /boot).

1 Like

Any userspace to kernel memory has been greatly limited by security changes to Linux in recent years. A lot of attacks were basically about doing that to root the system. Unlikely that the memory erasure test can tell you anything about data remnance related to the kernel. This is done in more complicated way according to the cold boot attack papers.

You cannot trust third party firmware to do the wiping for you as they could be buggy or maliciously designed to not do a good job.

You should make a poll to see how many DRAM 2 systems are in use and or have non-removable batteries. Note that for the latter this isn’t guaranteed to aid data remnance, but may in some cases do unlike older RAM families which will always have slower data decay.

Summary: only a kernel solution makes sense and it is only worth pursuing if a substantial (20%+) number of systems need it.

1 Like

Yes, we can’t wipe as much RAM without it but it seems complicated to implement.

The kernel already has a RAM wiping function, init_on_free which is what Tails uses. Tails just improves this and makes it wipe more by returning to the initramfs upon shutdown and unmounting the filesystem, thereby freeing more memory and having it wiped.

This essentially wipes all user space memory which is the most important part but leaves some kernel memory as the kernel cannot wipe itself hence why a complete implementation must be done at a lower level.

1 Like

@Patrick:

Avoiding all sidelines, keeping this simple, for my understanding and for the record and please correct me if I am wrong… Summary:

"cryptsetup close" of root device during shutdown is already implemented.

@poettering:

"cryptsetup close" of root device during shutdown is already implemented.

iff your initrd/distro of choice do so. For the root disk it doesn’t matter what systemd does, it matters what the initrd/distro do. hence ping the maintainers of those.

Debian feature request:
Wipe LUKS Disk Encryption Key for Root Disk from RAM during Shutdown to defeat Cold Boot Attacks from Initial Ramdisk (initramfs-tools or dracut)

Control: severity -1 wishlist
Control: reassign -1 cryptsetup-initramfs
Control: block -1 by 778849

Hi,

AFAICT dracut has dracut-shutdown(8) which you can extend at will, or
convince the maintainer to ship the required logic for everyone.
However Debian’s default initramfs, namely initramfs-tools(7) currently
has no interface to hook into at shutdown, and init doesn’t even hand
execution over to the initramfs during the shutdown phase (#778849).
When such an interface is available we can ship shutdown scripts into
cryptsetup-initramfs.

cheers
--
Guilhem.

related:
Support restoring initrd on shutdown and pivoting into it (#778849)

Maybe a good reason for replacing initramfs-tools with dracut.