Better strategy for dealing with malware on the SVS

[diracdeltas]

The current docs say, "As long as you're using the latest version of Tails, you should be able to open any document that gets submitted to you without the risk of malicious documents compromising the Viewing Station. However, if they do compromise it, Tails is designed so that the next time you reboot the malware will be gone."

I can think of a couple potential issues with this:

1. Hidden malware that gets written to the persistent volume will persist between reboots. We can mitigate this by disabling write-access to the persistent volume after the GPG key is generated there, but we'd have to change the documentation to stop telling journalists to copy encrypted files to the persistent volume. (Why not copy the files to the non-persistent TAILS volume? The reasoning wasn't clear to me from reading the documentation.)
2. Malware could be embedded in a submitted file that the journalist chooses to copy off the SVS to their Journalist Workstation, which has a much greater attack surface than TAILS as well as access to the Internet. Worst-case, the malware had access to sensitive plaintext documents on the SVS and thus bridges the airgap when it gets copied to the Journalist Workstation.

Fixing (1) might be especially hard because journalists will want to copy external software packages to the persistent volume so that they can be auto-loaded for viewing file types that TAILS doesn't natively support. It seems like it wouldn't be hard to hide malware in one of these packages.

[dolanjs]

We had been talking about this and while the documentation doesn't reflect the new install yet. It was planned to add that to their process. The journalist would have (1) 64GB drive for their personnel tails use (not the airgapped machine). (1) 64GB usb flash drive used for sneakernetting file back and forth to airgapped viewing station, (1) small <1GB drive for the airgapped viewing stations tail OS that would contain the private gpg key and 3rd party packages. (2) 500GB external hard drives for cold storage of encrypted documents.

[Taipo]

It might pay then to restrict the available extension types to known image, video and document types as one possible implementation because journalists adding in their own 3rd party packages to use with TAILS just sounds to me like an invitation for a FINFISHER type of attack.

The viewing station could then be best run on a DVD-R read only TAILS boot with the GPG key burnt into it?

Transporting files to be decrypted and viewed might be best done on small disposable USB drives, 'burners' or whatever other nickname you want to give to them, use them once and destroy them ( furnace ). Or is that going a bit too far?

[trevortimm]

@Taipo I've considered putting in the journalist best practice guide that journalists have a bucket of cheap USBs they use for transport. Once they use one once, they throw it out.

[Taipo]

Hmmmm now that I think about it, that then unfortunately creates the possibility for a KleptoDumpsteralogical Attack ( don't bother googling that, i just made that one up ) if the odd journo does not wipe and dispose of the great pile of USB sticks correctly.

Not to mention, buying that many on a regular basis could put them at risk of being sold 'preloaded' USB sticks from a national security lettered USB stick supplier...that may sound a bit far fetched, and maybe it is, but the harder we make this thing to crack, the more an adversary is left to such tactics which are currently being used for example against criminal gangs that buy burner cell phones by the boatload.

But certainly worth brain storming about, food for thought I guess.

[diracdeltas]

Ok, I'm proposing the following:

1. Change the docs to tell the journalist to decrypt the docs in regular Tails instead of the persistent volume. @micahflee can you see a reason not to do this?
2. Prevent journalists from decrypting files from multiple sources in a single Tails session so that a file from a malicious source never has access to the decrypted files from a legitimate source. Worst case: the journalist downloads a large number of files from multiple sources, one of which is malware. The malware can now erase/modify the plaintext of legitimate files, or even copy decrypted data to a hidden file in the USB stick that the journalist uses to transfer files between the SVS and his/her non-airgapped workstation.

@dolanjs is the Journalist supposed to use Tails on their personal workstation? I think that would be a good idea.

[dolanjs]

@diracdeltas yes they are suppose to use Tails on their personnel workstation when accessing the document interface.

Also think that the USB stick for transfering files from the document interface to the airgapped host and the USB stick that transfers the files encrypted w/ the journalist's personnel gpg key for publication from the airgapped host to a non tails OS should be different physical USB sticks.

[micahflee]

@diracdeltas nope, I wrote to copy it to the persistent volume, but really all I meant was copy it off of the USB stick, so that when they decrypt documents they don't end up there.

Also, non-persistent storage lives in memory. So if the documents are too big to fit into memory you'll have to use persistence. But this is an edge case.

However I'd also like to point out that this whole process is starting to seem very cumbersome, and like it can only be operated by experts. If we keep moving in this direction I think it's likely that journalists just won't follow the best practices. I don't have any better suggestions though.

[garrettr]

I second Micah's concerns about usability.

Have we considered using read-only media (CDs, DVDs) to copy files from the document interface to the viewing station? Would that prevent exfiltration of plaintext?

[diracdeltas]

@garrettr I don't see how using read-only media in the document-interface-to-svs step solves the problem of plaintext exfiltration, since all the files need to get copied to the Tails drive for decryption. I was assuming any attacks from malicious files would happen after decryption.

I agree that it seems like a huge usability cost to require journalists to decrypt files one source at a time. Maybe we could come up with a reliable way for them to check whether files had been modified between getting taken off the Document Interface and getting taken off the SVS.

[garrettr]

Discussed this with @diracdeltas, we agreed that using read-only media as part of the journalist's regular workflow would help reduce the attack surface and opportunity for exfiltration. However, they will eventually have to use writeable media to copy decrypted submissions elsewhere, either to work on them more (we can't assume a journalist will be able to do everything they need with Tails) or for publication. We also agreed that this is a low priority for now.

[heartsucker]

Marking as "Pending close" because this is in general covered by the Reading Room / journalist workstation.

[redshiftzero]

Agreed, the strategy here is the SecureDrop Qubes workstation, where each submission will be opened in a Qubes DispVM. Opened followup there: freedomofpress/securedrop-workstation#26