Critical PGP bugs. Do they possibly affect Split-GPG in Qubes?

[magione...@gmail.com]

I know that right now details are sketchy but the advice of disabling PGP is sound at least until we get to know more information, especially since it's coming from reputable researchers and the EFF (links below but I guess everybody here already knows about that), so obviously that there is ground for worry.

Do any of the Qubes users or devs know more at present about this issue or have advice to provide, aside from waiting for the publication of the research paper tomorrow morning (15th of May) and stopping using Split-GPG for the time being as a precaution?

https://www.eff.org/deeplinks/2018/05/attention-pgp-users-new-vulnerabilities-require-you-take-action-now

https://arstechnica.com/information-technology/2018/05/critical-pgp-and-smime-bugs-can-reveal-encrypted-e-mails-uninstall-now/

Thanks.

[Leo Gaspard]

I can't tell for sure for not having read the paper, but it sounds like
too much hype for vulnerabilities not so important:

https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060317.html

https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html
(Werner being the maintainer of GnuPG)

So I wouldn't worry about (but why not disable automatic
decryption/verification of incoming emails in the meantime, doesn't cost
much)

[mossy]

>> On 05/14/2018 10:33 AM, magione...@gmail.com wrote:
>> I know that right now details are sketchy but the advice of disabling
PGP is sound at least until we get to know more information, especially
since it's coming from reputable researchers and the EFF (links below
but I guess everybody here already knows about that), so obviously that
there is ground for worry.
>>
>> Do any of the Qubes users or devs know more at present about this
issue or have advice to provide, aside from waiting for the publication
of the research paper tomorrow morning (15th of May) and stopping using
Split-GPG for the time being as a precaution?
>>
>>
https://www.eff.org/deeplinks/2018/05/attention-pgp-users-new-vulnerabilities-require-you-take-action-now
>>
>>
https://arstechnica.com/information-technology/2018/05/critical-pgp-and-smime-bugs-can-reveal-encrypted-e-mails-uninstall-now/
>>
>> Thanks.

>'Leo Gaspard' via qubes-users:

> I can't tell for sure for not having read the paper, but it sounds like
> too much hype for vulnerabilities not so important:
>
> https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060317.html
>
> https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html
> (Werner being the maintainer of GnuPG)
>
> So I wouldn't worry about (but why not disable automatic
> decryption/verification of incoming emails in the meantime, doesn't cost
> much)
>
>

I would expect that if indeed this bug allows exfiltration of PGP
private keys, then qubes-splt-gpg would defend against this. Unless "an
oracle" does something magical that doesn't steal the PGP private key
directly (see below).

For our friends/colleagues/comrades who are especially concerned or who
are not yet qubes or qubes-split-gpg users, if HTML is the problem (as
Werner suggests) I suggest to mitigate as follows:

in the Thunderbird menu:
1) View -> Message Body As > [*] Plain Text
2) View -> [ ] Display Attachments Inline [should be NOT selected]

As I understand it, this works because split gpg doesn't expose private
keys to the mail client but instead sends encrypted emails to the vault
qube/AppVM for decryption.

My question for more knowledgeable friends here would be, what is meant
in Werner's message --
https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html -- by
"an oracle for modified encrypted mails"? My understanding of PGP is
that PGP/GPG encrypts/decrypts a short-lived symmetric key that is
actually used to encrypt/decrypt the message, so analysis of both the
plaintext and ciphertext of a single message would (at best, if this
were feasible) give you insight into the symmetric key, and not the PGP
private key itself.

But someone who understands more deeply, please enlighten us!

-m0ssy

[mossy]

mossy:

embargo broken early, attack/vulnerability details here --
https://efail.de/

(and yes it seems like disabling HTML will mitigate the most
reliable/least complex attacks)

-m0ssy

[Leo Gaspard]

On 05/14/2018 02:45 PM, mossy wrote:
> embargo broken early, attack/vulnerability details here --
> https://efail.de/
>
> (and yes it seems like disabling HTML will mitigate the most
> reliable/least complex attacks)

Incidentally, the GnuPG press release, that raises the point that the
paper may not be totally correct:

https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060334.html

Also if I understand correctly the latest exchanges from the GnuPG ML,
Enigmail 2.0 is safe from attack except for 3DES ciphertext, so the
attack could there only turn enigmail as a 3DES-ciphertext-decrypting
oracle.

[Ángel]

This paper is most interesting for the discovery of multiple ways email
client leak information on visualization.
(not clearly stated in the paper: some of them are already fixed, while
in other cases the developers are still working on providing them)

Luckily, with Qubes it is easy to set a firewall rule so that your email
AppVM can only contact with your email server.
NB that some of these leaks are dns-based, so ideally you would not
allow it to perform any dns query, either.

Best regards

[john]

can you give an example to the steps to make such a fw rule, if it's
that simple please ?

[799]

Hello John,

john <yre...@riseup.net> schrieb am Di., 15. Mai 2018, 07:23:

On 05/14/18 14:58, Ángel wrote:

> (...) 

> Luckily, with Qubes it is easy to set a firewall rule so that your email
> AppVM can only contact with your email server.
> NB that some of these leaks are dns-based, so ideally you would not
> allow it to perform any dns query, either.
>
>

can you give an example to the steps to   make such a fw rule,   if it's
that simple  please ?

You need to find out your Email-Server IPs:

https://github.com/one7two99/my-qubes/blob/master/docs/mail-firewall.md

Then you can use iptables in the Email AppVM to block all traffic as default rule.

Then only adding the traffic to the allowed IPs and ports.

I can send you my firewall script to allow email for outlook.com and Gmail.

[799]

[Eivind K. Dovik]

Through Qubes VM Manager, I've added the following firewall rule:

- Deny network access except ...
- IP address of my email server

This works fine.


> --
> You received this message because you are subscribed to the Google Groups
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-users...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/cd72c1d8-8293-0143-b6e8-70da0da12a95%40riseup.net.
> For more options, visit https://groups.google.com/d/optout.
>
>

[799]

Hello,

On 15 May 2018 at 09:24, Eivind K. Dovik <he...@eivinddovik.com> wrote:

On Mon, 14 May 2018, john wrote:

On 05/14/18 14:58, Ángel wrote:

  [...]
 

can you give an example to the steps to   make such a fw rule,   if it's that simple  please ?

Through Qubes VM Manager, I've added the following firewall rule:

- Deny network access except ...
- IP address of my email server
This works fine.

I prefer adding my rules to my AppVM. This is how do it:

1st you can check the connections which are request by running this command in your Email AppVM.

watch -n 1 'sudo netstat -tap'

It will show you if your email app connects to a server

But as most mail providers use more than one IP for load balancing you need to add more IPs (see my posting a few hours ago in this thread how do find the IPs your mail provider is using).

This are the rules I am currently applying to my Email AppVM.

You can put them into a script which loads on AppVM startup or copy & paste them into a terminal.

You need use sudo for the commands or switch to root via sudo -i (if you have sudo installed).

If you don't have sudo you can request a root terminal via qvm-run --auto --user root <APPVMNAME> gnome-terminal

- - - - 8< - - - - snip - - - - 8< - - - -

#show default policy
iptables -L -v | grep policy

# delete all rules
iptables -t filter -F

# change default policy to drop
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# allow DNS to gateway 10.137.1.1 (this is the sys-firewall)
iptables -A OUTPUT -p udp -d 10.139.1.1 --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT  -p udp -s 10.139.1.1 --sport 53 -m conntrack --ctstate ESTABLISHED     -j ACCEPT
iptables -A OUTPUT -p tcp -d 10.139.1.1 --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 10.139.1.1 --sport 53 -m conntrack --ctstate ESTABLISHED -j ACCEPT

# Allow outgoing ping/echo (only for troubleshooting / can be removed afterwards)
iptables -A OUTPUT -p icmp --icmp-type 8 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 0 -m state --state ESTABLISHED,RELATED -j ACCEPT

### allow IMAP (valid for germany, use other IPs you're from somewhere else)
# Gmail IMAP
iptables -A OUTPUT -p tcp -d 108.177.96.0/19 --dport 993 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 108.177.96.0/19 --sport 993 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp -d 74.125.0.0/16 --dport 993 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 74.125.0.0/16 --sport 993 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp -d 64.233.160.0/19 --dport 993 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 64.233.160.0/19 --sport 993 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp -d 108.177.8.0/21 --dport 993 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 108.177.8.0/21 --sport 993 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp -d 173.194.0.0/16 --dport 993 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 173.194.0.0/16 --sport 993 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp -d 66.102.0.0/20 --dport 993 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 66.102.0.0/20 --sport 993 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Outlook IMAP
iptables -A OUTPUT -p tcp -d 40.96.0.0/13 --dport 993 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 40.96.0.0/13 --sport 993 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

### allow SMTP
#Gmail SMTP
iptables -A OUTPUT -p tcp -d 74.125.0.0/16 --dport 587 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 74.125.0.0/16 --sport 587 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp -d 108.177.8.0/21 --dport 587 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 108.177.8.0/21 --sport 587 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp -d 108.177.96.0/19 --dport 587 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 108.177.96.0/19 --sport 587 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
#Outlook SMTP
iptables -A OUTPUT -p tcp -d 40.96.0.0/13 --dport 587 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 40.96.0.0/13 --sport 587 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# allow everything for localhost
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

- - - - 8< - - - -

[799]

[[799]]

Hello Eivind,

On 05/15 09:24, Eivind K. Dovik wrote:
> [...]

> Through Qubes VM Manager, I've added the following firewall rule:
>
> - Deny network access except ...
> - IP address of my email server
>
> This works fine.

please keep in mind that most email providers will use load-balancers for incoming requests.
As such you might need to add more than one IP to the firewall.
If you're using the Qubes GUI to add firewall rules:
If you enter a FQDN it will be translated to an IP-address when you enter the rule.
As such it might not work next time, if the load balancers route you to another IP.

regards

[799]

[Tai...@gmx.com]

I would suggest simply only allowing the ports you need for your email
client.

[Ilpo Järvinen]

It's much less secure approach than blocking all but the email server
address. With a port filter, the attacker only needs to use that same
port for the attack to succeed.

--
i.

[Leo Gaspard]

That's true, except HTML engines like the ones used by this attack
should disallow eg. loading an image from port 25.

For instance, firefox blocks at least ports 993 and 587, the only two
that should be used by a reasonably recent and secure email setup.

So that's not a solution against an arbitrary attacker, but that's a
solution against the currently-spoken-about attack.

BTW, if you really want to protect yourself from an arbitrary attacker,
you'll want to protect against an attacker that has root on your email
VM. And that means
1/ setting firewall rules in the FirewallVM, not in the email VM, as
the latter could just be removed by the attacker
2/ all kinds of hardening against side-channels for compromised VM
communication, that are currently not possible with Xen (and possibly
not even with any widely-spread hypervisor, as that would likely entail
a huge performance cost)

Another solution for 2/ could be to never run the email VM at the same
time as another potentially-compromised VM, but that very much restricts
what you can do. And that can maybe (now that's all hypothetical) still
be by-passed with side-channels through eg. LVM's thin pool allocator,
as IIRC Qubes4 uses LVM thin pools as storage backend. (still haven't
migrated…)