Tails

#1 Updated by segfault 2018-05-14 14:58:21

According to the appendix of the paper, there are two backchannels for Thunderbird on Linux: 1. using the HTML link tag, and 2. using OCSP requests to a fixed CA URL for S/MIME signed emails.
1. should be mitigated by Torbirdy, and 2. doesn’t affect GPG but only S/MIME. So I think we might be good.

#2 Updated by geb 2018-05-14 15:03:29

segfault wrote:
> According to the appendix of the paper, there are two backchannels for Thunderbird on Linux: 1. using the HTML link tag
> 1. should be mitigated by Torbirdy

I did a quick test and can confirm Thunderbird HTML rendering is actually disabled in Tails thanks to Torbirdy. Would be nice if somebody can confirm it.

Usul, it would be really valuable to have your opinion about this bug and possible Torbirdy mitigation if possible :-).

#3 Updated by geb 2018-05-14 15:40:27

geb:
> Usul, it would be really valuable to have your opinion about this bug and possible Torbirdy mitigation if possible :-).

Received a reply via another channel :

To create these exfiltration channels, the attacker first needs access to the encrypted emails, for example, by eavesdropping on network traffic, compromising email accounts, email servers, backup systems or client computers.
The attacker changes an encrypted email in a particular way and sends this changed encrypted email to the victim. The victim’s email client decrypts the email and loads any external content, thus exfiltrating the plaintext to the attacker.
if html is disabled, Torbirdy should be safe

#6 Updated by geb 2018-05-15 12:07:27

sajolida wrote:
> When I enable HTML rendering I often get another notification from Thunderbird but I’m not sure how it relates to E-Fail:
>
>> To protect your privacy, Thunderbird has blocked remote content in this message.
>
> So I wonder if Tails users who enable HTML rendering like me could still be affected or if that would also require enabling remote content.

According to a quick re-read of the EFail paper section 3.1, blocking external content should prevent automatic leak of information to third parties, like in example of this section (if the blocking is strict enough).

However, if you enable remote content, or if the attacker create a link and make the user click on it, it would lead to information leak.

#7 Updated by bmeson 2018-05-15 20:35:45

The version of Enigmail that ships with TAILS is vulnerable to EFAIL in a limited scenario.

There are a few concerns: the fixes to efail did go into Enigmail 2.0 but TAILS ships 1.9.9. Recommend targeting the package that ships with Debian Stretch (as far as I know) is 2.0.3. However, by default Thunderbird in TAILS disabled both remote content and displays emails as plaintext. The defaults are fine, unless a user changes the defaults to enable remote content and uses HTML email and uses a persistence volume. In that case, yes they are at a much higher risk for the (known) exfiltration paths.

There are at least two known MDC (error checking) bugs in GPG. The first is how many mail client implementations (otherwise known as MUAs) throw a WARNING and continue to decrypt. This is incorrect behavior as fixed in Enigmail 2.0 and described in efail. There is an additional vulnerability that was discovered with MDC checking that was reported in GPG opened today https://dev.gnupg.org/T3981 which will (likely) fixed in GPG 2.2. The version currently shipped Tails is 2.1.18 (the same as Debian). Note that to fully exfiltrate data, you have to combine both improperly implemented MDC checks and an exfil path as described in the second paragraph.

Most TAILS users are likely protected.

Best,
b_meson

#8 Updated by sajolida 2018-05-19 14:14:48

Regarding EFAIL and disabling HTML (default in Tails), the EFF FAQ reads:

Is disabling HTML sufficient?
=============================

Turning off sending HTML email will not prevent this attack. For some published 
attacks, turning off viewing HTML email may protect your messages being leaked
to an attacker by you. However, since PGP email is encrypted to both the sender
and each recipient, it will not protect these messages from being leaked by
anyone else you’ve communicated with. Additionally, turning off HTML email may
not protect these messages against future attacks that are discovered which
build off of the current vulnerabilities.

Turning off reading HTML email while still sending PGP-encrypted messages 
encourages others to read these with their own potentially vulnerable clients.
This promotes an ecosystem that puts the contents of these messages (as well as
any past messages that are decrypted by them) at risk.

On the other hand, the only alternative provided for now being to stop using OpenPGP all the way, this is not something that we can implement in Tails but rather something that users should implement themselves through a change of practices.

I’m still not really understanding EFAIL so I’m merely dropping here information that I find relevant for the specific context of EFAIL in Tails (and discussions that I’m seeing within our team over Redmine, XMPP, and email).

#10 Updated by intrigeri 2018-05-21 12:56:51

dkg’s writeup on this topic sets a number of things straight IMO, compared to what other organizations have been writing.

#13 Updated by sajolida 2018-05-22 10:02:50

Ah, and does anybody have info on when there could be upstream patches to fix some of this? In Enigmail? In Thunderbird? What will they do and when will they land in Tails?

#15 Updated by Anonymous 2018-05-22 11:50:41

sajolida wrote:
> Ah, and does anybody have info on when there could be upstream patches to fix some of this? In Enigmail? In Thunderbird? What will they do and when will they land in Tails?

Enigmail has a new version, but only uploaded to experimental for now. https://tracker.debian.org/pkg/enigmail I don’t know why dkg has not uploaded that to unstable, the changelog does not clearly say: https://salsa.debian.org/debian/enigmail/blob/debian/experimental/debian/changelog We can actively install this version in Tails if we want to.

As for Thunderbird, afaiu, the issue is fixed in TB60 (to be verified), which is also in experimental: https://tracker.debian.org/pkg/thunderbird

#16 Updated by intrigeri 2018-05-22 15:29:15

> Enigmail has a new version, but only uploaded to experimental for now. https://tracker.debian.org/pkg/enigmail

To track the next steps on the Debian side, see https://bugs.debian.org/898630.

My plan is to update to the version from experimental in Tails 3.8.

> I don’t know why dkg has not uploaded that to unstable

Enigmail 2.x is extremely hard to build from source (it bundles “minified” deps) and it’s unclear how dkg will address this. I’ve recommended him to upload to non-free, at least as an intermediary step.

> As for Thunderbird, afaiu, the issue is fixed in TB60 (to be verified), which is also in experimental: https://tracker.debian.org/pkg/thunderbird

It’s fixed in sid as well (https://bugs.debian.org/898631) and should be fixed in Stretch soonish ⇒ will be solved on our side via Bug #15607.

sajolida: I’d like a ticket to track fixing EFAIL in Tails 3.8, can I reuse/hijack this one?

#17 Updated by sajolida 2018-05-23 15:57:39

Sure…

If we decide to write a blog post I’ll do it elsewhere.

#20 Updated by intrigeri 2018-05-26 06:40:53

intrigeri wrote:
> > As for Thunderbird, afaiu, the issue is fixed in TB60 (to be verified), which is also in experimental: https://tracker.debian.org/pkg/thunderbird
>
> It’s fixed in sid as well (https://bugs.debian.org/898631) and should be fixed in Stretch soonish ⇒ will be solved on our side via Bug #15607.

Actually, Thunderbird 52.8.0 only fixes some aspects of EFAIL. The full fix is supposed to land in 52.8.1. I did not check yet if both Thunderbird 52.8.1 and the updated Enigmail are needed or if upgrading only one of those is enough.

#23 Updated by intrigeri 2018-05-27 08:06:18

> Actually, Thunderbird 52.8.0 only fixes some aspects of EFAIL. The full fix is supposed to land in 52.8.1.

Asked about that on https://bugs.debian.org/898631

> I did not check yet if both Thunderbird 52.8.1 and the updated Enigmail are needed or if upgrading only one of those is enough.

According to https://sourceforge.net/p/enigmail/forum/announce/thread/527a26fc/ one needs to upgrade both.

#29 Updated by intrigeri 2018-06-15 17:09:18

At least it passes our full test suite. Next step: test manually all kinds of Enigmail operations. And while I’ll do this I’ll look carefully at the AppArmor denial logs and will send MRs upstream as needed.

#31 Updated by intrigeri 2018-06-16 08:22:12

intrigeri wrote:
> segfault, can you please review & test this branch by the end of next week (June 24)?

I think that 15-30 min of focussed work should be enough. If for some reason you need more, let me know.

#32 Updated by segfault 2018-06-16 15:14:35

Regarding 144336e00521258d96b7dbced4e07439877eab0e: I think we can drop the protectHeaders preferences, they seem to be unused in Enigmail 2.0.

Regarding 80ca5660120ef50d656df07f832861d682501df7 I wrote on Bug #15610#note-6.

The rest looks good to me.

#35 Updated by segfault 2018-06-16 17:21:27

FTR, my assumption that the old preference is not used anymore is based on the diff of this commit: https://gitlab.com/enigmail/enigmail/commit/d2a0c88d21a5e4f7ca76e7a1e9e50345e973da70

#36 Updated by intrigeri 2018-06-16 17:24:17

> FTR, my assumption that the old preference is not used anymore is based on the diff of this commit:
> https://gitlab.com/enigmail/enigmail/commit/d2a0c88d21a5e4f7ca76e7a1e9e50345e973da70

I’ll git grep the hell of it!

#38 Updated by intrigeri 2018-06-17 09:21:00

I’ve tested at commit:8ef9cb8d34569d59a4c42a927fbfc20d6573293b:

• initial setup: a newly created account on an ISO built from the topic branch
• upgraded setup: a persistent account created on 3.7.1 then upgraded to the topic branch

… and in both cases, the new prefs were enough to disable encrypted headers by default, which matches my understanding of the code. So yeah, we can drop the old prefs :)

Note that I did not test the non-default case where a user has manually opted-in for protected headers on 3.7.1 or older (that’s in the hidden-by-default Enigmail expert prefs, at least in 1.9.x). I think that in this case, the custom pref will be lost along the way. Now, given Enigmail upstream has not bothered providing an automated migration path and that’s non-default, expert settings anyway, I don’t think it’s worth spending more time on it: I think it’s fair to say that one gets to keep the pieces when they use settings that are disabled by default and clearly labeled as “expert”.

But in the “upgraded setup” case the Enigmail setup wizard is started automatically, regardless of whether one already has a key pair; that’s super confusing so I’ll fix it.

#40 Updated by intrigeri 2018-06-23 07:25:17

This needs to be merged by the end of the week so it goes into 3.8.

I’ve addressed the issue you’ve raised here and replied to your concerns on Bug #15610 (where your concerns are not about a regression I would be introducing, but instead about a potential improvement that will require to trivially revert some of my changes whenever someone works on it). So if I don’t hear from you in time for the 3.8 ISO build, I’ll merge this branch anyway.

#42 Updated by segfault 2018-06-25 13:47:44

intrigeri wrote:
> This needs to be merged by the end of the week so it goes into 3.8.

Oh, by the end of the week you meant the end of last week. I’m sorry, I didn’t have the schedule for 3.8 in mind and thought I could do this early this week, after I finished my work for the VeraCrypt beta. Else I would have prioritized this higher.

#43 Updated by segfault 2018-06-25 14:08:20

I just reviewed the 3 commits which you pushed to the branch after my initial review and they look good to me.

intrigeri wrote:
> intrigeri wrote:
> > But in the “upgraded setup” case the Enigmail setup wizard is started automatically, regardless of whether one already has a key pair; that’s super confusing so I’ll fix it.
>
> Actually it’s not that bad: the default settings are to reuse the previous key pair. I’m worried that forcing Enigmail to skip this config update process may result in weird, hard to debug behaviour down the line. So I’d rather force users to go through that process once, to ensure they have an updated Enigmail config that works well with 2.x.

I would be willing to spend a few minutes investigating whether there are any incompatible settings between 1.x and 2.x which would justify to annoy our users with this setup dialog. But I guess now it’s too late for that :/

#44 Updated by sajolida 2018-06-25 19:26:31

So if I got it right, in 3.8 the EFAIL attacks on OpenPGP are fixed. The attacks on S/MIME will be fixed in Thunderbird 52.8.

See:

• https://admin.hostpoint.ch/pipermail/enigmail-users_enigmail.net/2018-May/004967.html
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898631

#45 Updated by intrigeri 2018-06-26 09:32:22

> So if I got it right, in 3.8 the EFAIL attacks on OpenPGP are fixed.

I think that’s the case but the word “mostly”, in “PGP handling seems mostly restricted to enigmail” (on the Debian bug report you’ve linked to), combined with the update I’m pointing you to below, makes me slightly doubt. I’ll reply on Feature #14682 wrt. the consequences on our public communication.

> The attacks on S/MIME will be fixed in Thunderbird 52.8.

That info is outdated. Not all fixes went into 52.8 (that we’re shipping since Tails 3.7.1) and some others will be fixed in 52.8.1. I don’t know for sure if the missing bits are purely about S/MIME or if OpenPGP is impacted as well.

#49 Updated by intrigeri 2018-06-29 06:26:21

Current theory is that Thunderbird 52.9 will be released next week.

#51 Updated by intrigeri 2018-06-30 12:57:20

intrigeri wrote:
> Current theory is that Thunderbird 52.9 will be released next week.

… but the last set of EFAIL fixes will be disabled by default in there (their author is not 100% comfortable with them) so we’ll need to enable them via a pref.

#52 Updated by intrigeri 2018-07-10 20:45:53

intrigeri wrote:
> intrigeri wrote:
> > Current theory is that Thunderbird 52.9 will be released next week.
>
> … but the last set of EFAIL fixes will be disabled by default in there (their author is not 100% comfortable with them) so we’ll need to enable them via a pref.

https://www.thunderbird.net/en-US/thunderbird/52.9.1/releasenotes/ says “Preference mailnews.p7m_subparts_external needs to be set to true for added security.”

#53 Updated by intrigeri 2018-07-10 23:12:21

Depending on Feature #15091 and in particular Feature #15091#note-40, we might need to update our ESR52 packages or skip directly to ESR60.

#56 Updated by intrigeri 2018-08-07 14:46:40

My understanding is that there will be no further 52.x ESR release so we’ll fix this via Feature #15091.

#60 Updated by intrigeri 2018-08-07 14:56:02

intrigeri wrote:
> > … but the last set of EFAIL fixes will be disabled by default in there (their author is not 100% comfortable with them) so we’ll need to enable them via a pref.
>
> https://www.thunderbird.net/en-US/thunderbird/52.9.1/releasenotes/ says “Preference mailnews.p7m_subparts_external needs to be set to true for added security.”

Done on the topic branch (commit:c3ab23dc52d1067f40e565aafaf8be39367c509d). Once I have an ISO with Thunderbird 60 I’ll verify that this pref is applied.