Is RAM Wipe possible inside Whonix? Cold Boot Attack Defense

nurmagoz · June 29, 2022, 11:28pm

secure-delete* package name in debian (sdmem: secure-delete memory)

Wipe mode is secure (38 special passes)
Using /dev/urandom for random input.

real 1m40.819s
user 0m0.072s
sys 0m0.163s

Wipe mode is insecure (one pass with 0x00)

real 0m0.503s
user 0m0.008s
sys 0m0.089s

Happen to me, i opened xfce-terminal and start moving it right and left until the screen freezed permanently (play for less than 3 minutes with anything like browse some stuff and open close terminal…).

Patrick · July 2, 2022, 8:43pm

github.com/dracutdevs/dracut

dracut-shutdown.service lacks DRACUT_SYSTEMD=1 environment variable

opened 08:42PM - 02 Jul 22 UTC

adrelanos

bug

**Describe the bug** dracut-shutdown.service lacks DRACUT_SYSTEMD=1 environme…nt variable **Distribution used** Debian but easily seen in dracut upstream source code: https://github.com/dracutdevs/dracut/blob/master/modules.d/98dracut-systemd/dracut-shutdown.service#L11 **Dracut version** latest git **Init system** systemd **To Reproduce** Write a shutdown hook and check for DRACUT_SYSTEMD variable existence. **Expected behavior** DRACUT_SYSTEMD=1 environment variable should be set during **Additional context** dracut-lib.sh looks at the DRACUT_SYSTEMD environment variable. For example, the `info` and `warn` functions of dracut-lib.sh require a properly set DRACUT_SYSTEMD. All other dracut systemd units in https://github.com/dracutdevs/dracut/blob/master/modules.d/98dracut-systemd/ are setting the DRACUT_SYSTEMD environment variable too.

github.com/dracutdevs/dracut

fix(dracut-systemd): set Environment=DRACUT_SYSTEMD=1 environment variable in dracut-shutdown.service

dracutdevs:master ← adrelanos:patch-1

opened 08:42PM - 02 Jul 22 UTC

adrelanos

+1 -0

## Changes * set Environment=DRACUT_SYSTEMD=1 environment variable in dracut-…shutdown.service ## Checklist - [x] I have tested it locally - [x] I have reviewed and updated any documentation if relevant: none required - [x] I am providing new code and test(s) for it: none required Fixes #1862

Patrick · July 3, 2022, 1:01pm

Huge progress has been made.

Implemented by dracut module cold-boot-attack-defense (by security-misc).

Will in near future be available for Kicksecure hosts. Should be easy to port to other Linux distributions.

See design documentation, review welcome:

More documentation, call for testers coming in near future.

Patrick · July 12, 2022, 5:15pm

Future design (additional kexec based RAM wipe) has been elaborated:
https://www.kicksecure.com/wiki/Dev/RAM_Wipe#Future_Design

Patrick · July 18, 2022, 9:38am

I’ll try to assign this task to implement also the future design to a contractor. Hopefully there will be a good news soon.

Patrick · August 4, 2022, 10:16pm

github.com/dracutdevs/dracut

dracut should unmount the root encrypted disk `cryptsetup luksClose` during shutdown

opened 10:15PM - 04 Aug 22 UTC

adrelanos

bug

**Describe the bug** dracut does not unmount the root encrypted disk on shutdow…n. (Using `cryptsetup luksClose`.) **Distribution used** Debian bullseye **Dracut version** 0.51 **Init system** systemd **To Reproduce** I've wrote a dracut shutdown module that runs `dmsetup ls --target crypt` which reports that an encrypted disk is still open. https://github.com/Kicksecure/security-misc/blob/master/usr/lib/dracut/modules.d/40cold-boot-attack-defense/wipe-ram.sh#L57 Also searching inside the dracut source code didn't yield any result for closing the encrypted root disk during shutdown. I am also seeing an error message during shutdown. (These messages are unreadable because shutdown is so quick. So I used a camera to record a video of the shutdown process to see these messages.) > device-mapper: remote ioctl on host--vg-root failed: Device or resource busy > device-mapper: remote ioctl on sda5_crypt failed: Device or resource busy > device-mapper: remote ioctl on host--vg-root failed: Device or resource busy > Powering off. That error message is probably caused by `/usr/lib/systemd/systemd-shutdown` because [`shutdown.c`](https://github.com/systemd/systemd/blob/main/src/shutdown/shutdown.c) includes `dm_detach_all`. `log_info("Powering off.");`. That could be a bug in systemd but indicates that dracut exitrd didn't properly clean up by running `cryptsetup luksClose`. These `Device or resource busy` messages are also reproducible on unmodified systems (no dracut modifications, no custom modules). Please let me know if you need better instructions how to reproduce this. **Expected behavior** dracut performs `cryptsetup luksClose` on shutdown. **Why should dracut perform `cryptsetup luksClose` on shutdown?** * Good style. * Everything dracut does to prepare the system for boot (initrd) should be undone, cleaned up during shutdown (exitrd) if it is reasonable to do so. This includes killing remaining processes, unmounting root and why not also `cryptsetup luksClose`. * Lower chances of data loss. If the root risk could be unmounted as well as the root luks device. By running `cryptsetup luksClose`, it increases chances that the kernel will flush all cashes and write them to the disk. * The time effort for `cryptsetup luksClose` on shutdown is really minimal but nice and clean. * systemd's `/usr/lib/systemd/systemd-shutdown` because [`shutdown.c`](https://github.com/systemd/systemd/blob/main/src/shutdown/shutdown.c) apparently also attempts to unmount the root encrypted luks disk (by calling function `dm_detach_all`). * Important for RAM wipe at shutdown to make sure (or at least increase chances) of releasing the luks disk encryption key - https://github.com/dracutdevs/dracut/issues/997 ---- **Search dracut source code for `luksClose`.** grep -r -i luksclose /usr/lib/dracut `90crypt/crypt-cleanup.sh` > `cryptsetup luksClose $i >/dev/null 2>&1 && do_break=n` `91crypt-loop/crypt-loop-lib.sh` > `printf "%s\n" "cryptsetup luksClose \"$key\"" > ${hookdir}/cleanup/"crypt-loop-cleanup-10-${key##*/}".sh` `90crypt/module-setup.sh` defines `inst_hook cleanup 30 "$moddir/crypt-cleanup.sh"` so that isn't about shutdown. `91crypt-loop/crypt-loop-lib.sh` isn't about shutdown either. I also couldn't find any `inst_hook shutdown` for any crypto related dracut module. grep -r -i hook /usr/lib/dracut | grep --color -i shutdown `99shutdown/shutdown.sh` runs `umount` but nothing related to crypto. In conclusion, I don't think that anything like "`cryptsetup luksClose`" at shutdown is currently implemented in dracut.

Patrick · August 13, 2022, 8:33pm

[systemd-devel] What is the shutdown sequence with systemd and dracut?

Patrick · January 7, 2023, 1:16pm

Patrick · January 9, 2023, 12:03pm

Migration from GitHub - Kicksecure/security-misc: Kernel Hardening; Protect Linux User Accounts against Brute Force Attacks; Improve Entropy Collection; Strong Linux User Account Separation; Enhances Misc Security Settings - https://www.kicksecure.com/wiki/Security-misc to

is in process.

Patrick · January 30, 2023, 11:52am

This was done.

Patrick · February 6, 2023, 7:24pm

This was implemented.

ram-wipe wipes the RAM twice during poweroff/reboot.

1. RAM Wipe Pass 1/2: During poweroff/reboot.

2. RAM Wipe Pass 2/2: It kexec’s into a new kernel for the purpose of overwriting the first kernel’s memory and performs a second ram wipe pass.

A dedicated user documentation wiki page has been created:

Patrick · February 8, 2023, 11:38am

If the following feature request gets implemented in memtest86+ that might result in a major security improvement for ram-wipe:

github.com/memtest86plus/memtest86plus

kexec into memtest86+ for RAM Wipe and reboot/poweroff - Cold Boot Attack Defense

opened 11:37AM - 08 Feb 23 UTC

adrelanos

[`ram-wipe`](https://www.kicksecure.com/wiki/Ram-wipe) ([source code](https://gi…thub.com/Kicksecure/ram-wipe)) ([design](https://www.kicksecure.com/wiki/Dev/RAM_Wipe)) is a software package that attempts to mitigate the threat of [cold boot attacks](https://en.wikipedia.org/wiki/Cold_boot_attack) as recently been developed (now primarily maintained by me). `ram-wipe` is currently based on `dracut` and `sdmem`. `dracut` seems very suitable for this task. In essence, `ram-wipe` drops back to initrd ("exitrd") at shutdown when all devices are already unmounted very late in the shutdown process, uses `sdmem` to overwrite all RAM, then `kexec`'s into a new (the same) kernel and does another pass of RAM wipe (to wipe the ram of the previous kernel). However, `sdmem` seems [unmaintained upstream](https://github.com/cryptisk-grs/thc-secure-delete/issues/3#issuecomment-520754476) and [has other issues](https://www.kicksecure.com/wiki/Ram-wipe#ram-wipe_Known_Issues). Research by [Tails](https://tails.boum.org/) seems to indicate that `memtest86+` is very suitable for wiping RAM at shutdown in principle. Much better than `sdmem`. See Tails blueprint [Erase memory: the memtest86+ way](https://gitlab.tails.boum.org/tails/blueprints/-/wikis/more_efficient_memory_wipe/memtest86plus). What would be need to be done at the memtest86+ side: * Support by memtest86+ to be booted using `kexec`. * Accept kernel command line parameters such as: * `wiperamaction`: * Overwrite all RAM once with zeros. * The action to perform after wiping the RAM. * `wiperamaction="poweroff"` * `wiperamaction="reboot"` * `wiperamaction="halt"` * Show a simple progress meter / messages for user. Such a feature might be appreciated by both [Kicksecure](https://www.kicksecure.com) and Tails, which are derivatives of Debian Linux as well as other users who discussed, requested a wipe RAM at shutdown feature all over the internet over the years. (Note, that I cannot speak on behalf of Tails.) Would you be interested to add a feature to memtest86+ to accommodate this use case or accept a patch?