Safely decrypting an unsolicited/untrusted PGP message

Question

I am accepting public security vulnerability reports for my website, and I publish my personal PGP (GPG) key to encourage people to encrypt their communications.

Upon receiving an encrypted message, what is the best way to safely decrypt it?

The encrypted message could contain any sort of untrusted/malformed data that could try to exploit my bash environment, my terminal emulator, etc.

I know that sometimes text can 'leak' out of command output into the prompt, meaning that pressing enter again would potentially execute arbitrary commands set by the attacker. One possible way to mitigate this is to completely end your session or close your terminal emulator and start a new one.

Any potential vulnerabilities in GnuPG or whatever PGP client I am using could also be exploited by the untrusted data.

Am I going too far with this risk or should I use an air-gapped single-use offline machine to decrypt each individual message, and securely erase it afterwards? What other security controls or practises can I put in place to help?

Thanks

Answer 1

##Dangers of printing untrusted text

The encrypted message could contain any sort of untrusted/malformed data that could try to exploit my bash environment, my terminal emulator, etc.

When outputting arbitrary text to a terminal, as GnuPG does by default, you are risking the exploitation of your terminal emulator. New vulnerabilities regarding handling of untrusted text being printed are found all the time, and while the most severe vulnerabilities have been weeded out, they are still an issue. One solution would be to pipe the untrusted output through a command that strips non-printing characters. You can use cat -v for this purpose. From section 3.1 of the coreutils GNU Info page:

-v
--show-nonprinting
    Display control characters except for LFD and TAB using ^ notation
    and precede characters that have the high bit set with M-.

Printing untrusted text while stripping non-printing characters should prevent exploitation of your terminal emulator through mishandled control codes or any other typical avenue of attack.

$ gpg -d untrusted.gpg | cat -v

##Dangerous of decrypting untrusted messages

Any potential vulnerabilities in GnuPG or whatever PGP client I am using could also be exploited by the untrusted data.

This is also a risk. GnuPG is incredibly complex, and any parsing of complex data can lead to exploitation. The only solution would be to run GnuPG airgapped, or in a tight sandbox or properly isolated virtual machine. GnuPG v2 has improved its architecture, allowing the decryption to occur in a process which has no access to your private key, but this is far from a complete sandbox. In general, you should always assume that a sufficiently competent attacker will be able to exploit GnuPG through way of providing you with a maliciously malformed encrypted message.

A quick search turned up several bad vulnerabilities in GnuPG in the past 10 years:

• CVE-2008-1530 - Memory corruption via duplicate keys from keyservers allowing code execution.
• CVE-2010-2547 - Use-after-free vulnerability in certificate parsing allowing code execution.
• CVE-2013-4242 - Side-channel attack revealing private key information to local processes.
• CVE-2013-4576 - Side-channel attack allowing acoustic cryptanalysis during RSA decryption.
• CVE-2016-6313 - Broken RNG leaking 160 bits of random material, weakening certain key types.

##But what is the actual risk?

Am I going too far with this risk or should I use an air-gapped single-use offline machine to decrypt each individual message, and securely erase it afterwards? What other security controls or practises can I put in place to help?

An airgapped machine would do nicely, but may not always be an option. There is no need to securely erase the messages afterwards, as an unlinked (deleted) message poses no risk. The only reason to try to securely delete something is if you do not want it to be available through forensic analysis.

Overall, the actual risk should be fairly low. Exploiting a popular program requires a certain level of expertise which is unlikely to be used to compromise you through your website unless you are high profile, or very unlucky. There are easier ways to be compromised through an exploit that via GnuPG messages (for example, hyperlinks to compromise your browser, images to compromise image parsers, etc). Even so, there are a few things you can do to reduce this risk with regards to GnuPG:

• Decrypt messages using an unprivileged, or better yet dedicated, user.
• Strip control codes from decrypted output. Never view raw output with vim, less, etc.
• Keep GnuPG up to date at all times so known vulnerabilities will be patched on your system.
• Use the virtual terminal and not a terminal emulator. Never use xterm or related forks.
• Use AppArmor or similar on GnuPG. Do not run it under a user with X11 access.

Answer 2

This is only a part of an answer, because forest already covered a lot of ground.

It's the outputting untrusted text that I am most worried about.

You can easily avoid handling untrusted text in the terminal. First, in your mail client, store the encrypted gpg block in a file, for example /tmp/encrypted_message.txt

Then, in the terminal, run

$ gpg ... -o /tmp/decrypted_message.txt ...

So now you have the decrypted message in /tmp/decrypted_message.txt without ever having untrusted data touch the terminal/shell. Open the decrypted file in any application you trust to display it, or e-mail it back to yourself (since you already use that to display untrusted text whenever you receive an unsolicited message, so you're not increasing the attack surface).

You should worry about other things

Running shell commands hidden in user input is actually a likely attack vector, because lots and lots of systems are vulnerable to this, so from the attacker's view it pays to develop the necessary evil payloads, and from your point of view it's clever to remove the shell from your pipeline when handling user input whenever you can. But by storing the encrypted untrusted input in a file and having gnupg output the decrypted text into another file, you've already eliminated all contact between untrusted data and the shell.

Instead, you should now worry about flaws in the rest of your pipeline's applications. gpg could contain a flaw that let an attacker run arbitrary machine code (usually code that gives an attacker a shell) on your computer. But gpg features in far less pipelines than, say, a webbrowser or a mail client, so It seems unlikely an attacker would pick GnuPG to look for flaws that allowed him to run shellcode, instead of the much more often used webbrowsers and mail clients, (unless he targets GnuPG users or you specifically, of course - someone might be targeting GnuPG users, but there are so many high-exposure software packages that seem like better targets that I think you'd primarily have to worry about someone who actually targets you or your website, individually).

Airgapping to read messages users of your website send to you sounds way over-cautious to me unless you're running the next Silk Road and are afraid US law enforcement is after you, in which case I could understand why you worry. But if you do want to isolate gpg, you can use software such as firejail. This means that an attacker who has found a flaw in GnuPG that allows him to run arbitrary code will also have to find a flaw in the linux kernel before he can escape from the jail into your actual system and do more damage.

(Edit: Changed the answer to reflect the discussion in the comments/chat)