Tails

#1 Updated by mercedes508 2019-02-05 16:20:11

• Assignee set to intrigeri
• Type of work changed from Code to Research

Already received a report about this issue. Not sure what we can do from a Tails perspective as said here https://labs.riseup.net/code/issues/12545#note-5

#2 Updated by intrigeri 2019-02-05 17:07:52

• Assignee changed from intrigeri to s7r

Dear s7r, can you please triage this?

#3 Updated by s7r 2019-02-05 21:17:14

• Status changed from New to Confirmed
• Priority changed from Normal to Elevated
• Type of work changed from Research to Wait

This is confirmed.

Some important notes:

- there is no vulnerability in the application itself. Nothing can be exploited. The only bug is that the arbitrary error message sent by the malicious server is displayed as rich text by QT.

- because of how electrum server peer discovery works, there is nothing that can stop the sybil attack or filter the servers. There’s no authoritative directory which assigns flags or reputations to servers. Any client using auto-connect or random server has the N % chances to run into a malicious server where N = the % of the malicious servers in the server pool.

- it is a phishing attack. if the users use a trusted server, or a honest server, they are unaffected. If the users use a malicious server, get the error but don’t follow up and don’t install Electrum from untrusted sources, and just simply switch servers, they remain unaffected.

- the fix upstream in 3.3.3 ONLY renders error messages to plain text instead of rich text, and doesn’t allow arbitrary messages but strict error codes.

- in Tails it’s not trivial to install something from other sources, so I aim to think Tails users are OK.

At the moment, the network of Electrum servers is sybil-ed with malicious peers, there are so so many.

ElectrumX (the Electrum server implementation) 1.9.3 was tagged which:

a) filters and identifies most malicious peers (servers) and does not further broadcast them to clients;

b) uses the same “bug” to display a WARNING that the users should upgrade, even thus the transaction was successfully sent.

This was done because, users simply don’t upgrade in the wild, and remain vulnerable to the phishing scam.

Electrum’s Debian package maintainer had some problems that did not allow him to work on Debian, and when I last discussed I understood that work will be resumed at mid February, which is soon. It’s going to be tight with the Buster freeze, but let’s see what happens.

This is what we are waiting for in order to close all Electrum tickets. There is nothing much we can do in Tails, except display a notification on the website, or maybe even in Tails itself, that all Electrum users will either:

a) get a phishing message that will advice them to install a backdoored Electrum from an untrusted source, message that should be ignored.

b) get a warning message that the transaction was sent, but the version of Electrum used is vulnerable. This will be fixed in another release.

c) provide some trusted onion Electrum servers so that they don’t have to go through many servers until they find one that broadcasts their transaction, since the Electrum server pool is heavily sybiled at this moment.

Comments from more people needed here, to see what’s the best way here.

#5 Updated by sajolida 2019-03-18 13:39:27

• related to Feature #16565: Mention Electrum updates on the doc/known issues page added

#6 Updated by sajolida 2019-03-19 18:00:59

• related to Bug #16564: Consider shipping Electrum as an AppImage added

#7 Updated by sajolida 2019-03-19 18:01:05

• related to Feature #16565: Mention Electrum updates on the doc/known issues page added

#8 Updated by sajolida 2019-03-19 18:01:25

• related to deleted (Feature #16565: Mention Electrum updates on the doc/known issues page)

#10 Updated by intrigeri 2019-04-04 11:32:52

• QA Check set to Info Needed
• Type of work changed from Wait to Communicate

Provided guidance on the thread (https://lists.autistici.org/thread/20190320.121811.e9a13ab3.en.html), we’ll decide how to proceed once s7r has answered the questions we have :)

#11 Updated by intrigeri 2019-04-04 11:33:08

• Target version set to Tails_3.14

#12 Updated by CyrilBrulebois 2019-05-23 21:23:31

• Target version changed from Tails_3.14 to Tails_3.15

#13 Updated by intrigeri 2019-06-02 15:12:50

• QA Check deleted (Info Needed)

#14 Updated by CyrilBrulebois 2019-07-10 10:34:12

• Target version changed from Tails_3.15 to Tails_3.16

#15 Updated by intrigeri 2019-08-14 06:48:11

• blocks Bug #16969: "Electrum starts" test step is broken on Buster added

#16 Updated by intrigeri 2019-08-14 06:52:15

• Status changed from Confirmed to In Progress

Applied in changeset commit:tails|f092b0d6f268a12550283e3a510f0455055ca1d9.

#17 Updated by intrigeri 2019-08-14 06:52:57

• Description updated
• Status changed from In Progress to Confirmed

#18 Updated by CyrilBrulebois 2019-09-05 00:05:38

• Target version changed from Tails_3.16 to Tails_3.17

#19 Updated by intrigeri 2019-09-08 06:21:54

• blocks Feature #16209: Core work: Foundations Team added

#20 Updated by intrigeri 2019-09-08 06:29:49

• Assignee deleted (s7r)
• Target version changed from Tails_3.17 to Tails_4.0
• Type of work changed from Communicate to Code

Electrum 3.3.8-0.1 is now in sid. It installs just fine on Buster. Additional dependencies that need to be pulled from sid too: python3-aiohttp-socks, python3-aiorpcx, python3-electrum.

For Tails 4.0, let’s try to upgrade to this version and reintroduce + fix the corresponding test cases (Bug #16969).

Implementation-wise, I’m undecided whether it’s better to:

• install it from sid ⇒ increased risk of breakage happening just before a Tails code freeze
• install it from Bullseye ⇒ there’s no security support for testing so it’ll be our job to monitor whether security fixes landed in sid but did not migrate to testing yet; we have no mechanism in place for this; we already have this problem in other areas (Feature #14728) but it may not be a sufficient reason to make it even worse

Thoughts?

#21 Updated by intrigeri 2019-09-08 06:35:21

• blocks Bug #9732: Orca cannot work with Electrum added

#23 Updated by segfault 2019-09-18 19:51:10

• Status changed from Confirmed to In Progress
• Assignee set to segfault

#24 Updated by segfault 2019-09-21 16:36:55

• Feature Branch set to bugfix/16421-fix-electrum

On the feature branch, Electrum is installed from Sid. It seems to work: I can start it and create a wallet. I haven’t used Electrum before, so I don’t know what else I can test. @s7r, maybe you want to have a look? You can download the image here:

https://nightly.tails.boum.org/build_Tails_ISO_bugfix-16421-fix-electrum/lastSuccessful/archive/build-artifacts/tails-amd64-bugfix_16421-fix-electrum-4.0-20190920T1734Z-3bba768b94+devel@fe2c7513ee.img

#29 Updated by segfault 2019-10-01 21:48:32

• Status changed from In Progress to Needs Validation
• Assignee deleted (segfault)

s7r wrote:
> I have tested it from: tails-amd64-bugfix_16421-fix-electrum-4.0-20190927T1734Z-3bba768b94+devel@fe2c7513ee.iso
>
> It works perfectly. We are being notified about persistence.
> I have actually simulated some transactions to send / receive with it on top and with it minimized in the background and the notifications in the top bar work just fine (Electrum sent XXX or received XXX). I have generated both Segwith (new type) wallet as well as legacy wallet. I have tested the on the fly config file automated update (Electrum implemented a new config_version parameter and it is able to identify the current config file version and update it to the daemon version requirements, ignore deprecated features, etc.) and it works perfectly as well. I will comment more about this on Bug #15483 about this.
>
> All tests pass AFAICT.

Great, thanks!

#30 Updated by intrigeri 2019-10-02 07:09:51

• blocks Bug #15483: Update Electrum configuration file added

#34 Updated by intrigeri 2019-10-02 09:41:19

• Assignee set to intrigeri
• Feature Branch changed from bugfix/16421-fix-electrum to bugfix/16421-fix-electrum+force-all-tests

I’ve merged current devel into this branch to repair its build.

I’ve renamed the branch so that the fragile scenario reintroduced by this branch is run on Jenkins: that’s the only automated scenario we have that actually tests Electrum (the other scenario merely tests the warning dialog that we display when starting Electrum without persistence).

I’ll come back to it tomorrow, once Jenkins has tested build reproducibility and has run this scenario.

#35 Updated by intrigeri 2019-10-03 05:20:23

• Status changed from Needs Validation to In Progress
• Assignee changed from intrigeri to segfault

intrigeri wrote:
> I’ve renamed the branch so that the fragile scenario reintroduced by this branch is run on Jenkins: that’s the only automated scenario we have that actually tests Electrum (the other scenario merely tests the warning dialog that we display when starting Electrum without persistence).

Unfortunately, that newly reintroduced scenario fails on Jenkins.

> I’ll come back to it tomorrow, once Jenkins has tested build reproducibility

This fails as well. I believe that’s because a translatable string was changed on the branch and it would be fixed by refreshing the PO files.

#36 Updated by segfault 2019-10-03 08:17:17

• Assignee deleted (segfault)

Maybe someone else wants to look into why the test fails.

#37 Updated by segfault 2019-10-03 08:18:38

• Priority changed from Elevated to Normal

#40 Updated by segfault 2019-10-03 16:02:32

• Assignee set to segfault

#41 Updated by segfault 2019-10-04 18:49:50

• Status changed from In Progress to Needs Validation
• Assignee deleted (segfault)

I couldn’t fix Bug #16969, so I removed the test from the branch.

#42 Updated by intrigeri 2019-10-05 06:48:44

• Assignee set to intrigeri

#44 Updated by intrigeri 2019-10-05 11:21:54

• Status changed from Needs Validation to Resolved
• % Done changed from 0 to 100

Applied in changeset commit:tails|ae8f4b8cbb97e655025318ad78831064c867c8ab.