[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Is RAM Wipe possible inside Whonix? Cold Boot Attack Defense

Development
#1

I am pretty new here compared to most of you, and probably not half as knowledgeable, but still I’m trying to help out best I can.

For the past two weeks or so I have been messing around with Whonix 14 trying to implement different methods of RAM erasure that I have been able to locate.

I found a guideline on Tails website in their design subject about how they go about it on a page titled “Memory Erasure”. I’m still working on trying to implement that in Whonix, but I have heard of some accomplishing this task on Debian so I feel it could be possible. If I am wrong about that I would love to know why cause I have been working quite hard at implementing it.

Aside from that I have also tried tools like sdmem which was quite easy to use as a solution on shutdown, but I have heard it to not be as effective as one would want. I am also checking out memtest86 as a possible solution, but still I fear that may suffer the same problems.

Has anyone else been working on this feature mostly for the live system that could point me in the right direction, or simply tell me if I am wasting my time. I just think this would be a wonderful feature to be available on Whonix. An amnesiac system with the added security provided by isolation Could really change things. A lot I have spoken with about this idea are quite excited by it so I have been working hard to make it possible, I just don’t know if it is indeed possible or not.

Tails Documentation

https://tails.boum.org/contribute/design/memory_erasure/

1 Like
Whonix live mode / amnesia / amnesic / non-persistent / anti-forensics
Install memlockd by default? (daemon to increase system reliablity during low RAM)
Enable Secure Memory Encryption (SME) - kernel parameter mem_encrypt - by default?
#2

If you can make it work on Debian, that solution will also work for Whonix.

Related:

#3

https://tails.boum.org/contribute/design/memory_erasure/ sounds like its working. Documentation looks very good.

Just needs to be properly Debian packaged. Looks doable.

Could you package it please? There are a ton of examples in Whonix source code. Packaging using genmkfile is simpler than usual packaging.

https://github.com/Whonix/grub-live

Please remove any /local from file paths.

Only the .c file could be a bit more difficult to package. But that one looks only required for “USB boot medium is unplugged or boot DVD is ejected”. We could compile it perhaps using the postinst method.

Adding a systemd unit file simple example commit: https://github.com/troubadoour/tor-control-panel/commit/0a4fc8a90f4f916ee2091d84d7da24690cce0d36
(add dh-systemd to Build-Depends: in debian/control;
use dh $@ --with systemd;
add systemd unit file to lib/systemd/system/name.service)

#4

But I thought with DRAM3 and beyond the danger of data lurking in memory after a shutdown was no longer a problem since it forgets it with a couple of seconds

#5

I am terribly sorry about the delay in reply Patrick, there were some personal issues that needed tended to.

I checked out the code, and gave it a test run on Debian. It works amazingly. This is exactly what I had been trying to do but I hadn’t been able get it working right, but this code is well awesome to say the least.

I would be more than happy to work on packaging it for you if it will help. It may not be the most important feature in the eyes of a lot of people, but I say if the data can be thoroughly wiped very fast upon shutdown without causing issue I see no reason why it shouldn’t be.

1 Like
#6

The USB feature doesn’t apply too much to us so I see what you are saying, but it would be neat to have the option to set a drive as a key of sorts that would initiate the shut down the machines when removed like with the USBKill program. I’ll look closer at it shortly. If it won’t be doable right now I’ll package the wipe for shutdown.

I think something that would really be something would be if we could get a wipe function working for Qubes with the live system. I guess that’s something to worry about in the future, for now I’ll just focus on the package for Debian.

1 Like
#7

By all means, I find this very important to have a swell. Would love to have any kind of enhancement packaged and then being picked up by packages.debian.org. From there, future iteration enhancements are doable over time.

#8

Sorry I have been slow packaging it, I was mixing and matching code from the memory erasure page, and the wiperam tree. I think I have found a setup that works pretty well in Debian without too much issue. I just have to go through and see which files I worked with cause I regretfully was not keeping track. Though I think I have figured out most of my misunderstandings. I’m confident I can quickly repeat it on a clean system with as simple of package as possible.

Getting the system to return to initramfs, and too unmount the root file system is easy once everything is in the right place, but it does not really do anything unless the user has page poisoning enabled in the kernel and /proc/cmdline.

It is really simple solution to accomplish this, relying on tools that come with the system mostly aside from a couple dependencies like memlockd.
I am still working on getting the package to include a way of making sure page poisoning and such are enabled, or actually enabling them itself if that is possible. I’m not sure, but from the ones I have seen it seems most newer Linux Kernels at least have the feature enabled, all that leaves is modifying the GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub. Doing that and reloading a grub config file with the new parameters shouldn’t be too hard to automate if I get to it soon, but I want to start working on some thorough documentation on how to configure the system manually until I can automate the process. The memory erasure page was good enough for the more tech savvy that especially can read the code in the program files to see which files or such they require aside from the ones mentioned. It doesn’t really give you the slightest idea on how to check your kernel settings, and add parameters for page poisoning which is something I feel a lot of people are not very familiar with.

I’m not the most savvy in the bunch, I read that page a hundred times before I finally understood what it was saying and I know a lot who rely on these systems even know much less than I cause I’ve been trying to help them figure it out. What I’m saying is that it makes implementing this seem way more complicated than it needs to be. It just needs step by step instructions, and it will be easy. I am willing to do this as well with the package,in a README file, especially if someone gave me a hand with grammar cause it is not my strong suit.

Really it is something anyone should be able to set up in 10 minutes, but most are just guessing what to do with the files it gives, and don’t understand how any of it works. I think it can be easily explained to the point that we can start to get a lot of eyes working on this making it better.

1 Like
#9

Something else I’m scared to do before putting it in a package is that I can’t really tell if page poisoning is actually active even though enabled. I’m new to messing around with the kernel but I think I figured out how to get it enabled. My thing is nothing visibly is happening other than what was, no screen distortion or anything to indicate to me that it is actually doing what it is supposed to.

Perhaps I have something set up wrong and just can’t tell, or maybe it is just not something you notice. Either way even though all shutdown signals suggest everything is working as expected, I still cannot tell for sure that the left over memory was wiped before the system powered down.

I am looking for a way to test this to make sure that it is doing what it is supposed to. Tails website mentioned a couple tests I saw that I will look into but I think those were geared towards their outdated wipes but I will make sure. If anyone is more familiar with page poisoning and related features and knows how to accomplish this I am all ears as this parameter does not seem much discussed on-line though this feature relies upon it.

I really wanna make sure this works cause I do not want to package something that claims to wipe sensitive data that is actuallynot doing anything. I know it is little threat, but it could compromise the freedom of some that rely on stuff like this.

I’ll get what I got packaged and load it on a nonofficial site for you to see if I messed anything up adding the files hopefully tonight in a directory structure of where they are all to go, as well as a list of dependencies, and everything else needed to replicate what I have working right now. I’m hoping one of you guys smarter than me can find a way to verify that this simple little trick actually wipes the RAM in the same manner as tails, or if something just is not working.

Basically I will sort of package it using the tool you suggested probably to make it easier on you guys, but I don’t think it is something we should even suggest normal users to attepmt just testing, cause it may be doing nothing, or if set up wrong it could screw up there system or just cause problems that none of us could’ve guessed cause we haven’t had time to really examine how this feature holds up under a number of different tests, that it opens no potential holes, is quick, and just actually does what I’ve been working at for a couple weeks.

1 Like
#10

Also do not mean to flood the thread, but I’ve been thinking about mixing up the watchdog patches a little to work more like USBKill in a way. Really simple stuff as far as I can tell to have it instead of looking for a boot drive to be removed to force the shutdown procedure, that i can look for a whitelisted usb device, or watch out for unauthorized ones to initiate it. I think that would help a lot of people. The watchdog procedure Tails has for this is very aggressive. It seems to take complete priority, as well as very difficult, if at all possible to stop. That would be an awesome security feature for even if someone just tried to steal your laptop, you could have a string attached to your key drive so when it is ripped out of your hands the drive is removed, and a near unstoppable shutdown security feature initiates immediately.

I may be speaking beyond myself but I think I could get that to work with enough effort. I at least think it would be cool cause you could send an imediate shutdown system to both Whonix machines with the simple pull of a flashdrive.

I’ll let someone else speak now I’ll get back to work.

#11

Please use .d folder instead.

/etc/grub.d/30_package-name.cfg

This can be mimicked:

github or https://phabricator.whonix.org/T800 please.

Sounds great!
Specifically since you can use a long USB cable and then connect the USB device to the table, body or whatever people think is best. Once the notebook is taken away, it shuts down and RAM wipes, sounds amazing!

#12

While I can see how this can be accomplished for a single VM where you just attach the USB device, I don’t see a way to do this easily for both at the same time. imo the feature would ideally be implemented on the host. In that case both VMs would get shut down. I’d personally also feel much better if everything gets shutdown including the host.
For testing the efficiency of the memory wipe, at least with KVM/libvirtd you can do memory snapshots. You can also take a look at Rekall and Volatility.

#13

Algernon:

While I can see how this can be accomplished for a single VM where you just attach the USB device, I don’t see a way to do this easily for both at the same time. imo the feature would ideally be implemented on the host. In that case both VMs would get shut down. I’d personally also feel much better if everything gets shutdown including the host.

Of course on the host. Didn’t mean to imply inside the VM.

#14

Any update @Jonah?

#15

I still don’t think this is a really neccessary feature. @HulaHoop already mentioned that for DDR3 RAM forensics is hard. There are presentations and slides available online from the people who did the original research on that and I guess they spend quite a while on this. Even they said it is hard to do and memory decays quite fast. So the attack is possible, but not really feasible. We have DDR4 since a while and I could not yet find any research on that which either means no one did it or someone tried and it did not work. Afaik with increasing speed it gets even harder and maybe future RAM generations fix the scrambling in a way that it can not be easily reverted.
When someone is in the position to mount a cold boot attack against you he is likely also in the position to use some more efficient ways to get your cryptokeys and what not. I never came across cold boot attacks in the wild but there have been several examples of the latter.
I also wouldn’t want to rely on some software feature while you can easily cut the power which should work in 100% of the cases. You can also put the device somewhere where it’s warm so RAM decays faster :wink:

1 Like
#16

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

#17

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.

#18

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.

#19

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
#20

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

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]