Project

General

Profile

Feature #7432

Investigate security issues that may be caused by passing SSL_NO_VERIFY unchanged to tails-upgrade-frontend

Added by intrigeri about 5 years ago. Updated over 2 years ago.

Status:
In Progress
Priority:
Elevated
Assignee:
Category:
-
Target version:
-
Start date:
06/21/2014
Due date:
% Done:

20%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
No
Affected tool:
Upgrader

Description

We pass SSL_NO_VERIFY unchanged via sudo from the amnesia user to the tails-upgrade-frontend program. Presumably, an adversary who has taken control of the amnesia user, and can actively MitM the connection to https://tails.boum.org/, can 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). Note that the upgrade-description file being served still needs to be signed by the Tails signing key.

We should investigate the exact consequences of this all.

3.png View (302 KB) kurono, 11/25/2015 09:40 AM

History

#1 Updated by sajolida about 5 years ago

  • Target version set to Hardening_M1

#2 Updated by intrigeri almost 4 years ago

  • Assignee changed from intrigeri to kurono

#3 Updated by kurono over 3 years ago

  • File 3.png View 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 over 3 years ago

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

#5 Updated by intrigeri over 3 years ago

  • 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 over 3 years ago

  • Target version deleted (Tails_2.3)

#7 Updated by BitingBird about 3 years ago

  • Status changed from Confirmed to In Progress

#8 Updated by intrigeri almost 3 years ago

  • Target version set to Tails_2.6

#9 Updated by intrigeri almost 3 years ago

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

#10 Updated by intrigeri over 2 years ago

  • 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 over 2 years ago

  • 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 over 2 years ago

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

#13 Updated by kurono over 2 years ago

intrigeri wrote:

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.

No problem :)

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.

Ok, I will take a look of them.

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.

Ah sure you are right!

  • 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.

If an attacker has amnesia's user access, he can manipulate all the processes the normal user
would have access to, so it is possible to block the upgrade process. As an example
an attacker could try an advanced version of:

while true; do xdotool search "zenity" windowkill %@; done
zenity --info --text="There are not updates available." --width=200 --height=200

This way the user would not notice even that something happened.
It depends of course when the attacker start having access to the system,
if he can do it anytime before the user has finished the upgrade process
(I guess he could even kill the upgrade GUI in the middle of the update).

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!

Sure I will keep working on this :)

Also available in: Atom PDF