3

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

  • Unless there is a hideous bug in PGP / GnuPG nobody has discovered yet, your worries have no basis in fact. Attacking the decryption process of GPG messages doesn't seem promising to me at all. – Pascal Feb 17 '18 at 1:01
  • 1
    You always cat decrypted emails directly from the shell? Wow, that's hard-core. – symcbean Feb 17 '18 at 1:24
  • 1
    If you're concerned about something messing with bash or the terminal, why not send the output to a file? – multithr3at3d Feb 17 '18 at 1:48
  • @Pascal Actually, GnuPG is rather hideous. It is not only sane, but very smart to be worried about this. – forest Feb 17 '18 at 4:12
  • @forest: Really? You'd be worried about being attacked by a security vulnerability report someone encrypted with PGP/GnuPG? Don't you think that if GnuPG poses a problem in the described context, then whatever process OP has in place to handle these reports is also susceptible to an attack that doesn't involve GnuPG? If OP is worried about shell scripts getting executed by mistake, then obviously there is a much more serious problem in the pipeline he uses. GnuPG / PGP aren't the main issue here. – Pascal Feb 17 '18 at 10:00
5

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.
  • Thanks for the great answer. The reason I suggested securely erasing the air-gapped machine is to help remove any potential compromise. After decrypting one untrusted message, I would consider that machine fully compromised, so erasing it would help with this. – jamieweb Feb 17 '18 at 13:04
1

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)

  • Thanks for the helpful answer. My current 'pipeline' for resolving an encrypted vulnerability report would probably be eg: Receive report via email, copy encrypted GPG text into stdin/file, run it through GnuPG and read the output. I've never actually done this though specifically because of this question I am asking. What would you say actually is the general process for decrypting untrusted GPG messages? Many companies accept GPG messages so they must have some process in place to handle this risk. Thanks – jamieweb Feb 17 '18 at 13:14
  • Also regarding the air-gapped machine idea, the reason I suggested air-gapping is so that any compromise is contained. Actual message confidentiality isn't as important here as the machine would be completely offline once the messages to decrypt had been transferred over, and would be reformatted before breaking the air-gap again. Although this doesn't mitigate compromises that can survive a reformat, such as firmware-level attacks. The transfer method would also have to be secure, such as a single-use flash drive or perhaps an email account. – jamieweb Feb 17 '18 at 13:18
  • Well, see, you're worried about a bug in GnuPG that will allow an attacker to run abritrary code. But what about a bug in your E-Mail-Client which you use to open your e-mails in the first place (or your browser, if you use webmail)? I'm having trouble seeing why you focus so much on the PGP/GnuPG vulnerabilities, when there are so many other things to worry about. I don't think a company that accepts GPG messages especially worries about there being an exploitable bug in GnuPG. Ubuntu trusts it enough to verify signatures with it whenever you install software packages. – Pascal Feb 17 '18 at 16:35
  • Still, if you do worry that someone might target GnuPG because they know you're using it, you could add some isolation even without an airgap, for example by using "firejail". Your attacker would then need to exploit a GnuPG bug PLUS a serious linux kernel bug to even break out of the jail. – Pascal Feb 17 '18 at 16:41
  • It's the outputting untrusted text that I am most worried about. Regarding the email client and everything else involved in the process, I am aware that those are also risks, however outputting untrusted text to my terminal is probably much more risky than say opening a spam email using Thunderbird. – jamieweb Feb 17 '18 at 21:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.