Tails

#1 Updated by sajolida 2014-07-10 15:08:43

• Target version set to Hardening_M1

#2 Updated by intrigeri 2015-10-14 12:04:19

• Assignee changed from intrigeri to kurono

#3 Updated by kurono 2015-11-25 09:52:13

• File 3.png added
• QA Check set to Info Needed

Here I will divide the research in two sections, the first to explore the possibility of
indefinite freeze attacks, and the second for rollback attacks.

Indefinite freeze attack:

Tools used:

• Tails 1.6.
• Proxychains 3.1-6
• mitmproxy 0.13

Scenario:
The idea is to check whether tails-upgrade-frontend running inside Tails is vulnerable
to Indefinite freeze attack. To achieve that one can use Proxychains to forward all the
connections made by tails-upgrade-frontend to a custom http proxy server with
mitmproxy.

If an attacker has control over the amnesia user, he could just download the Proxychains
binaries without really installing them. Then the attacker could run something like:

LD_LIBRARY_PATH=./.libs/ DISABLE_PROXY=1 SSL_NO_VERIFY=1 ./proxychains /usr/bin/tails-upgrade-frontend

This makes tails-upgrade-frontend to redirect all its traffic to a proxy server (configured in proxychains.conf),
and also to not verify the tails.boum.org certificate. Then it is possible to serve fake upgrade-description files
by mitmproxy. At this point the attacker only needs to serve old upgrade-description files to trick the user.

Results:
By running the above scenario, we get the following results:

Which shows that the Indefinite freeze attack is possible. However there are some considerations:

• Using proxychains only works if the attacker calls tails-upgrade-frontend directly.
  If tails-upgrade-frontend-wrapper is used, it does not work because in this case a different user
  is called (tails-upgrade-frontend via sudo), so the amnesia user can not include the proxychains libraries.
• The attacker still have the possibility to use a tor exit node to provide an old upgrade-description
  file. However in this case the attacker would require to launch a large scale attack to increase
  the possibilities of attacked Tails systems reaching its rogue exit nodes.
• Of course, an attacker that has control over amnesia can use its own tails-upgrade-frontend-wrapper
  to trick the user, but maybe this is beyond the scope of the current research.

I will wait for feedback in order to proceed with the research on the rollback attack,
to be sure I am going in the right direction.

#4 Updated by kurono 2015-11-26 07:51:29

• Assignee changed from kurono to intrigeri
• % Done changed from 0 to 20

#5 Updated by intrigeri 2016-02-18 16:24:29

• Target version changed from Hardening_M1 to Tails_2.3

Sorry for the delay. Don’t hesitate asking others to review your work if I’m too slow.

#6 Updated by intrigeri 2016-04-17 02:11:37

• Target version deleted (Tails_2.3)

#7 Updated by BitingBird 2016-06-26 10:52:18

• Status changed from Confirmed to In Progress

#8 Updated by intrigeri 2016-08-01 07:07:53

• Target version set to Tails_2.6

#9 Updated by intrigeri 2016-09-12 02:19:25

• Target version changed from Tails_2.6 to Tails_2.7

#10 Updated by intrigeri 2016-11-09 20:18:18

• Assignee changed from intrigeri to kurono
• QA Check changed from Info Needed to Dev Needed

Hi!

I am very, very sorry to have been constantly postponing this for almost a year. Since a while guilt feelings have started blocking me from even looking at this ticket, which is stupid and counter-productive, but well. Stupid brain.

> Here I will divide the research in two sections, the first to explore the possibility of indefinite freeze attacks, and the second for rollback attacks.

Sounds good. At some point we’ll also need to check the other potential attacks (https://tails.boum.org/contribute/design/incremental_upgrades/#security-discussion) that might be relevant here though: I don’t remember if / how much I checked that when I wrote “e.g. serve an old upgrade-description file that hides the availability of an upgrade (indefinite freeze attack), or maybe even incitates the user to downgrade to an older version of Tails (rollback attack)” 2.5 years ago.

> Indefinite freeze attack:
[…]
> This makes tails-upgrade-frontend to redirect all its traffic to a proxy server (configured in proxychains.conf), and also to not verify the tails.boum.org certificate. Then it is possible to serve fake upgrade-description files by mitmproxy. At this point the attacker only needs to serve old upgrade-description files to trick the user.

OK.

> Which shows that the Indefinite freeze attack is possible.

I suspected that. Thanks for demonstrating it.

> However there are some considerations:
> * Using proxychains only works if the attacker calls tails-upgrade-frontend directly.
> If tails-upgrade-frontend-wrapper is used, it does not work because in this case a different user
> is called (tails-upgrade-frontend via sudo), so the amnesia user can not include the proxychains libraries.

Note that an active network adversary, sitting between the Tor exit node and our web site, does not need to use proxychains.

> * The attacker still have the possibility to use a tor exit node to provide an old upgrade-description file. However in this case the attacker would require to launch a large scale attack to increase the possibilities of attacked Tails systems reaching its rogue exit nodes.

… or sit somewhere near the upstream Internet connectivity provider to our website.

> * Of course, an attacker that has control over amnesia can use its own tails-upgrade-frontend-wrapper to trick the user, but maybe this is beyond the scope of the current research.

Right.

Now, taking a step back, regarding the indefinite freeze attack: Tails does check for upgrades automatically. Either the attacker can block this process, or they can’t.

If the attacker can block the check for upgrades: they won, regardless of the whole SSL_NO_VERIFY thing, as the user simply won’t be told about available upgrades.

Else, if they cannot block the check for upgrades:

• it’s basically irrelevant here whether the attacker can run their own, fake, check for upgrades that will always tell “no upgrades”: the only thing they win out of it is confusing users (who’ll be told both “no upgrades” and “please upgrade”), and with arbitrary code execution as the amnesia user, they can simply do that with zenity, regardless of the whole SSL_NO_VERIFY thing;
• presumably they can’t modify it either in order to make it use SSL_NO_VERIFY (which would allow them intercept the request and reply with an old UDF). As far as I understand it, this “presumably” is the last thing to check. If I guessed right, then SSL_NO_VERIFY is not a concern wrt. indefinite freeze attack. Do you want to have a closer look from this perspective?

> I will wait for feedback in order to proceed with the research on the rollback attack, to be sure I am going in the right direction.

I think you’re totally in the right direction, so please do proceed if you’re still interested/excited by this topic :)
I suspect that the rollback attack scenario will be much more interesting, as the attack can be conducted in a way that’s fully independent from the check for upgrades we do. Also, I suspect that much of the reasoning above will apply, so the work you did already will be re-used!

#11 Updated by intrigeri 2016-11-09 20:18:47

• Assignee changed from kurono to intrigeri
• Target version deleted (Tails_2.7)
• QA Check changed from Dev Needed to Info Needed

#12 Updated by intrigeri 2016-11-09 20:19:04

• Assignee changed from intrigeri to kurono
• QA Check changed from Info Needed to Dev Needed

#14 Updated by kurono 2020-04-28 12:39:18

• Assignee deleted (kurono)