Does opening a video file only write to memory and not to disk?
That depends on the video player. There is no fundamental reason that a video player would need to write to the disk, but I cannot guarantee that there is not one somewhere that saves things to disk on its own. If you have swapping enabled, then some memory from the video player may be written to the disk in order to free up memory. You should either use encrypted swap space, or disable swap to avoid this issue.
If it does write to memory, how easy is it for a relatively sophisticated attacker with hardware access to recover the media from memory?
Very easy. Forensic tools like Volatility can view the process tree from a memory snapshot and dump individual processes. Analysis of those processes will allow reading buffers containing video data out from the program. Getting the memory requires only being able to plug in a PCIe device and mounting a DMA attack. Most systems do not protect from this.
Are there secure programs to open and play such a video file without leaving a recoverable memory footprint? Follow-up: can this be practically done without Tails?
How do you expect a video to be played without anything touching memory? If your worry is about residual memory after the program closes and the system is shut off, just make sure you have modern memory (anything newer than DDR2) and powering off the system will result in data in memory vanishing in seconds. Note that video data may also reside in VRAM on your graphics card for a short time as well, and cold boots on graphics cards are possible.
You can use encrypted swap along with full disk encryption and ensure your system is powered off before "they" get to it. That way, even if video contents are written to the disk, at least it is encrypted.
Repeat 1, 2, 3 for images and text.
This all applies equally to images and text. Video has a larger memory footprint, but just being small does not make something immune from being written to disk or remain in memory.
I agree with @SteffenUllrich. You need to define your threat model. For each of his example threat models, the following should hold true:
Is the media still playing if the hacker gets access to the device?
In this case, the attacker would be able to read anything from memory. There is no effective way to prevent this. Solutions that encrypt entire memory are often highly experimental, limited in scope, or extremely slow. Some newer AMD processors come with the ability to encrypt all memory, however, which would be ideal for these purposes if you expect the attacker to get their hands on the system but are unable to compromise it (e.g. limited to cold boot attacks, not DMA).
It is done playing but the device is not rebooted?
If it's done playing then some data may still reside in RAM. This data would most likely include parts of the page cache which cache recently accessed files. This can stay in memory for a long time. Additionally, when a process exits, the kernel frees the memory it used but it does not initialize the memory to zeros until it is requested by another process. The PaX hardening patches allow it to initialize the memory immediately when pages are unmapped or the process exits, and there are new kernel configuration options which can "poison" memory on free, at some performance cost.
Was the device shutdown or rebooted?
If the device was shut down completely, everything in both system RAM and video RAM will have been destroyed in a matter of seconds. DRAM works by storing each bit of information in a very small capacitor, and refreshing any charged capacitor every 64ms so it keeps its charge. Reading a bit involves checking the state of the capacitor, and setting a bit involves either charging or discharging the capacitor. When memory loses power, it is no longer refreshed, and every capacitor rapidly decays to the same state (with microscopic sizes of these capacitors, charge is leaked very fast).
But how does this apply to a reboot? The problem is, a reboot does not cut power to DRAM, it merely resets the CPU and some devices, which means the DRAM continues to refresh, keeping its old contents until overwritten. After all, RAM doesn't know what state your computer is in. It just knows that it has been configured and is receiving power. There are a few reasons that this memory may not be persistent across a simple reboot:
- Memory was intentionally overwritten before a reboot, as it is in Tails.
- Your BIOS is configured to test all memory during POST after a reboot.
- You are using ECC RAM, which by design must be reset to a specific state after reboot.
In the end, you should probably be using Tails as it is designed with anti-forensics in mind. There are only a few things to remember in order to prevent an attacker from recovering video history:
- Do not save any data to an unencrypted storage medium. Stick with Tails' encrypted persistence.
- Make sure you never leave your computer unattended, especially while it is running.
- Make sure your system is powered down before allowing anyone to get near your computer.
- If someone has unrestricted physical access to your computer, it's not your computer anymore.