[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Is RAM Wipe possible inside Whonix?


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


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


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


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


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


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