Project

General

Profile

Bug #7023

Mitigate security issues caused by using the Tails website as the browser homepage

Added by molibdeedee over 4 years ago. Updated over 1 year ago.

Status:
Confirmed
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
04/04/2014
Due date:
% Done:

0%

QA Check:
Feature Branch:
bugfix/7023-disallow-javascript-on-our-website
Type of work:
User interface design
Blueprint:
Starter:
No
Affected tool:
Browser

Description

Set the homepage of the iceweasel/torbrowser in tails to point to a local file.
Reasons:
1)By opening the same homepage everytime you start tails, or choose "new identity," increases the probability of a drive-by/mitm attack on tails.boum.org or whatever site is the home page. Whatever page is choosen will become a more serious target for compromise, either directly or mitm.
2)It seems this would also be a vector for a timing attack on the local connection, for what it is worth, since you know every browser circuit will go to that page.
3)Some users may want to change their noscript or other settings before connecting to any page.

Associated revisions

Revision e94a43bd (diff)
Added by intrigeri about 3 years ago

Tor Browser: block JavaScript coming from our website.

This limits a little bit the attack surface that's implied by having our website
as the default Tor Browser's homepage, and thus loaded by most Tails users soon
after startup: a non-negligible proportion of Tor Browser security issues don't
apply if JavaScript is disabled.

Still, as said on https://labs.riseup.net/code/issues/7023#note-7, this is not
a complete solution. Tackling this problem for real needs more research, to find
a way to convey important project news to our users without having them
systematically load our website.

Refs: #7023

Revision da579e61 (diff)
Added by intrigeri about 3 years ago

Tor Browser: block JavaScript coming the news section of our website.

This limits a little bit the attack surface that's implied by having our website
as the default Tor Browser's homepage, and thus loaded by most Tails users soon
after startup: a non-negligible proportion of Tor Browser security issues don't
apply if JavaScript is disabled.

Still, as said on https://labs.riseup.net/code/issues/7023#note-7, this is not
a complete solution. Tackling this problem for real needs more research, to find
a way to convey important project news to our users without having them
systematically load our website.

Refs: #7023

History

#1 Updated by BitingBird over 4 years ago

  • Priority changed from Elevated to Normal

#2 Updated by sajolida over 4 years ago

1)By opening the same homepage everytime you start tails, or choose
"new identity," increases the probability of a drive-by/mitm attack
on tails.boum.org or whatever site is the home page. Whatever page
is choosen will become a more serious target for compromise, either
directly or mitm.

I don't understand your point here. What kind of mitm attack are you
talking about? And how would they affect the user?

2)It seems this would also be a vector for a timing attack on the
local connection, for what it is worth, since you know every browser
circuit will go to that page.

Tails already connects automatically on our RSS feed for security when
starting. Do you think that having two connections instead of one
increases this risk?

3)Some users may want to change their noscript or other settings
before connecting to any page.

The current homepage has no Javascript.

Plus, we chose to display our news page because we feel it is important
for the users as well as for the project to keep them informed this way.

#3 Updated by grnstar over 4 years ago

I don't understand your point here. What kind of mitm attack are you
talking about? And how would they affect the user?

I think molibdeedee has a valid point here. He is referring to the homepage tails.boum.org. In case that gets compromised an adversary can theoretically put malicious code on that page and since all Tails users have java script enabled by default all an adversary would need is some malicious to compromise thousands of Tails in a really short period of time before it is discovered.

Tails already connects automatically on our RSS feed for security when
starting. Do you think that having two connections instead of one
increases this risk?

Again going back to my earlier point, I think having all Tails users visit one page on startup of their browser is a huge op-sec error. Whether it's from comprimising tails.boum.org or just simple traffic analysis, an attacker can get a better idea. In other words if an adversary does traffic analysis they can deduce that the user has just started their Tails and connected, which gives them more intel.

_The current homepage has no Javascript.

Plus, we chose to display our news page because we feel it is important
for the users as well as for the project to keep them informed this way._

You are correct in that in has no javascript, but if it is compromised an attacker can inject malicious code into thousands of Tails users browsers.

Your news page is informative but personally I don't think it's worth it at the cost of a users security.

Ideally the Tails news page can be a bookmark in the default Tails browser and the homepage can be a simple about:blank page or point to a local file (ex. default.html) which has a simple message of tails connected and have a few obvious links point to Tor check page and Tails news.

Other than the obvious privacy and security benefits the icing on top would be a faster load time due to the browser loading a local html file as opposed to a remote one.

#4 Updated by intrigeri over 4 years ago

  • Type of work changed from Code to Discuss

#5 Updated by darkgrid over 4 years ago

For the time being until this issue is fixed here is how I go about it:

1. before connecting to a network open the firefox browser and right-click and turn on no-script

2. connect to the network

This way when tor connects and auto launched my browser it already has no-script on instead of off by default.

In reality the chances of the Tails homepage being compromised is very low however we shouldn't ignore it just because the change is low.

Things have happened in the past where the chances were really low and people never thought it would be possible but it happened (ex. FBI inserting malicious java script which phones back home to an undisclosed server).

The easiest solution would be to put a simple local html file with some basic info and links to Tails news and the Tails homepage.

#6 Updated by sajolida over 4 years ago

I think molibdeedee has a valid point here. He is referring to the
homepage tails.boum.org. In case that gets compromised an adversary
can theoretically put malicious code on that page and since all Tails
users have java script enabled by default all an adversary would need
is some malicious to compromise thousands of Tails in a really short
period of time before it is discovered.

Ok, I understand now. Your concerned is not necessarily about a MitM but
rather about the original page getting compromised in general.

Tails already connects automatically on our RSS feed for security
when starting. Do you think that having two connections instead of
one increases this risk?

Again going back to my earlier point, I think having all Tails users
visit one page on startup of their browser is a huge op-sec error.
Whether it's from comprimising tails.boum.org or just simple traffic
analysis, an attacker can get a better idea. In other words if an
adversary does traffic analysis they can deduce that the user has
just started their Tails and connected, which gives them more intel.

A "better idea" of what exactly?

Such an adversary should be able to look at both the local ISP and the
destination server in order to what? Identify someone as a Tails user?
Identify the user of a Tor circuit that could be reused shortly after?

First of all, we do not pretend it is possible to strongly hide the fact
that you are using Tails in the current state of things.

See https://tails.boum.org/doc/about/fingerprint/

Second, Tor cannot really preserve your anonymity from a global
adversary that can observe both your local ISP and the destination
server. Whether you are visiting tails.boum.org, google.com, or anything
else.

See https://tails.boum.org/doc/about/warning/#index7h1

So for me, the only possible attack that would be prevented by a local
file would be in case our homepage gets compromised.

By the way, could you find in the Tor bug tracker any archive on why
they decided to use a local file?

Ideally the Tails news page can be a bookmark in the default Tails
browser and the homepage can be a simple about:blank page or point to
a local file (ex. default.html) which has a simple message of tails
connected and have a few obvious links point to Tor check page and
Tails news.

If we decide to not connect to the news page, then the solution you
decide seems good to me.

#7 Updated by intrigeri over 4 years ago

  • Subject changed from Make homepage point to a local file like torbrowser to Address potential issues caused by using the Tails website as the browser homepage
  • Status changed from New to Confirmed
  • Priority changed from Normal to Low
  • Type of work changed from Discuss to Research

Notes from the monthly meeting:

  • using a local homepage (with links to key pages) would make it less
    likely that users read our news, and people who see the "not enough
    memory to check for upgrades" thing won't know that there's a new
    Tails available.
  • if our website is compromised (either locally, or via SSL MitM with
    help from a rogue CA), then we have many other problems: e.g.
    the attacker can block all kinds of security update notifications
    (incremental upgrades, security check) forever, trick users to
    download random ISOs, etc.
  • we could configure NoScript to block JavaScript on tails.boum.org,
    and mitigate the concern about exploitation of the browser via JS on
    the homepage; OTOH, not all firefox security issues require JS, so
    it doesn't really solve much of the problem.

=> this needs research, to find a good solution.

#8 Updated by molibdeedee2 over 4 years ago

Ideally the Tails news page can be a bookmark in the default Tails browser and the homepage can be a simple about:blank page or point to a local file (ex. default.html) which has a simple message of tails connected and have a few obvious links point to Tor check page and Tails news.

A local file would better match traffic behavior of Tor Browser. If that can be done for free, why not?

using a local homepage (with links to key pages) would make it less
likely that users read our news, and people who see the "not enough
memory to check for upgrades" thing won't know that there's a new
Tails available.

This is a valid point. However, one that a user might only want to see when they first start tails, not every time they use the "new identity" feature.

I think the solution is to:
1) Insure connections RSS or whatever to check for updates are done in
a) seperate circuit,
b) once, and
c) when tails network connection is established and working.
d) Ideally with wget or curl, which is probably more secure than browser and doesn't execute javascript code.
2) Use a local file similar to torbrowser.

Such an adversary should be able to look at both the local ISP and the
destination server in order to what? Identify someone as a Tails user?
Identify the user of a Tor circuit that could be reused shortly after?

The difference is, the adversary in this case doesn't have to know something special about you to know your dest server. They know you will connect to tails.boum.org:443. And they know that will happen on every browser circuit. They don't have to be a "global adversary." They could be watching tails.boum.org, or they could be a malicious admin. So by watching someone's local connection, and by watching tails.boum.org, they can determine fairly easily, your exit node for each circuit. They can then match up these ip's with other ips in other logs they may have access to, to determine, for instance, that you connected to a particular web-based email/hidden service/whatever. By removing the constant hitting of tails.boum.org, we get back to having to be a global adversary, or having specific knowledge of user. Removing the homepage limits "intelligence."

Having the homepage also makes tails.boum.org more highly desired to be compromised. As far as ISO's, people should be, and are, highly cautioned to verify images via PGP. As far as rouge CA, we know this is a legitimate attack. Compromise could be instantaneous for thousands of users, and seems low-hanging fruit compared to other compromise methods.

It is also hard to say what a particular user might be interested in doing. A highly cautious user may not use the browser at all. But someone in between, may wish to have JS disable ASAP, or other needs for setting up browser we may not be aware of. Perhaps such a user knows a zero-day that can be fixed via about:config page, and wants to fix that before connecting http/https to anything. Its hard to say. I think a solution to this needs to have the user notified of updates, but not introduce new threats.

#9 Updated by molibdeedee2 over 4 years ago

The key thing here that puts this in a seperate category then other threats, is the garunteed and repeated connecting to the same resource. This is not the case with any other page a user may access. A global adversary is not necessary, just someone who can watch local and/or tails website.

When me must connect to a particular resource for every instance of running tails, then that connection should be as secure as possible.

As far as I know, we clearly connect to the dir servers and then entry guards. We connect to the servers for setting the date. And then the update server RSS. On the Tor side, nothing we can or should do about that. All other mandatory connections we must do the best we can to insure the best security possible since they are the lowest hanging fruit for an attacker.

The current homepage has no Javascript.

Well that could be changed by the attacker.

#10 Updated by molibdeedee2 over 4 years ago

The core points with this (bug):
  1. The connection happens on every browser circuit.
  2. By design, browser circuits do not use IsolateDestAddr/Port flags. The "New Identity" feature of TorButton clears the browsers history and requests a new tor circuit for subsequent connections.
  3. An adversary only needs local timing information, and ability to watch tails.boum.org, in order to determine exit nodes for browser circuits. The adversary does not have to be a "global passive adversary." If adversary was a "global passive adversary," then the connection to tails.boum.org, could only make things easier for them.
  4. Having times and exit nodes, adversary can then, at a later time, find other logs and determine with decent surety, that the user connected to those other pages.
  5. Adversaries have shown the ability to mitm https sites through rouge CA. Generally what we seen has been JS, but it is agreed this may not be necessary. Additionally, attacker can modify the page. The attacker is motivated to do so, as every tails user will connect there, whereas other arbitrary pages, there is no such motivation.
  6. Users should be verifying ISO images via PGP.
  7. Other connections that tails makes to check for updates, date, etc, (should) happen in other IsolateDestAddr circuits using (theoretically) more secure wget/curl etc.

As simple solution seems to be to just point to a local file as the homepage, as the Tor Browser currently does.

#11 Updated by techfx over 4 years ago

molibdeedee2 really hit the nail on the head with this one. The only reason I can see why Tails developers are persistent in not changing it is due to the anonymous metrics data they collect from that homepage.

But a question I have for the Tails developers is whether the anonymous stats they collect from the homepage worth it at the cost of putting all Tails users in jeopardy? The homepage being a remote site as opposed to a local file gives the adversery far too much intel.

We want to do everything we can to make it very difficult for the adversy. Whether they are doing traffic analysis or some other method, having all Tails users arrive at the same homepage upon connecting seems like we are going in the wrong direction when it comes to security and privacy.

The easiest and most privacy friendly solution would be to have a local html file with a heading stating "Tails Connected" and a few obvious links pointing to Tails News & Tor Check.

#12 Updated by sajolida over 4 years ago

The only
reason I can see why Tails developers are persistent in not changing
it is due to the anonymous metrics data they collect from that
homepage.

But a question I have for the Tails developers is whether the
anonymous stats they collect from the homepage worth it at the cost
of putting all Tails users in jeopardy?

By the way, we don't collect stats from the visits on that page. We only
collect stats on the security check that warns if new versions are
available. Note that this doesn't happen in a browser but through a
command-line tool for fetching that page. And I definitely think this is
worth it in term of added security for the user.

See https://tails.boum.org/blueprint/faq#boot_statistics

#13 Updated by intrigeri over 4 years ago

The only reason I can see why Tails developers are persistent in not
changing it is due to the anonymous metrics data they collect from
that homepage.

This is untrue. We don't collect metrics from that homepage.

#14 Updated by t3x over 4 years ago

Since no stats are collected on the Tails homepage I honestly can't see a logical reason to use a remote url instead of a local html file.

Can someone please explain where the logic is in giving the adversary more intel and making all Tails users upon connecting all arrive at the same location?

Just makes no sense to me when it comes to Tails users security and privacy to set one url that thousands and thousands of Tails users arrive at as their homepage.

#15 Updated by intrigeri over 4 years ago

I honestly can't see a logical reason to use a remote url instead of
a local html file.

Please (re-)read comment 7.

(Don't get me wrong: I'm not saying the current state of things is
perfect, I'm saying it solves an actual problem we had, and it would
be great if whatever other solution someone designs does not
reintroduce it.)

#16 Updated by sajolida over 4 years ago

Another proposal would be to set NoScript to block all JavaScript on our homepage by default.

#17 Updated by broncospasm about 4 years ago

...I was just gonna say, and sajolida beat me to it, and intrigeri beat the both of us to it with "meeting notes" mentioned above:

we could configure NoScript to block JavaScript on tails.boum.org,
and mitigate the concern about exploitation of the browser via JS on
the homepage; OTOH, not all firefox security issues require JS, so
it doesn't really solve much of the problem.

This would at least help. Some compromises are partial, and all an attacker can do is manage to insert javascript... and that could be enough. Personally, I think there should be a big fat warning about NoScript being OFF by default on whatever the "home page" is, but that's probably for another discussion.

I think it would be a good compromise for now.

In spacey futuristic ideas, what about cryptosigning the home page and fetching it by RSS as part of browser launch, with a reasonable timeout (and a cache if persistence is enabled, maybe)? Then there's only one connection.

I also think having the "home page," if remote, be on a .onion might be something to consider for reasons similar to those I mention for switching DuckDuckGo search to the DDG .onion in #6059: there's no traffic over the clearnet, no jammed-up exit nodes to go through, and no delay from TCP 3-way handshake and latency between the exit node and the site. If DDoS can be mitigated or dealt with, having the home page on a .onion and denying Javascript on it doesn't mitigate all risk if an attacker gains access to tails.boum.org, but it does mitigate some traffic/timing correlation attacks and lag IMO.

#18 Updated by BitingBird about 4 years ago

  • Category set to 176

#19 Updated by intrigeri almost 4 years ago

  • Subject changed from Address potential issues caused by using the Tails website as the browser homepage to Mitigate potential security issues caused by using the Tails website as the browser homepage

#20 Updated by intrigeri about 3 years ago

  • Target version set to Tails_1.6
  • % Done changed from 0 to 10
  • QA Check set to Ready for QA
  • Feature Branch set to bugfix/7023-disallow-javascript-on-our-website

Please review'n'merge. Note that this ticket should not be closed after merging, as this is a very partial solution.

#21 Updated by intrigeri about 3 years ago

Passes encryption.feature, torified_browsing.feature, unsafe_browser.feature, windows_camouflage.feature.

#22 Updated by sajolida about 3 years ago

  • Assignee set to intrigeri
  • QA Check changed from Ready for QA to Info Needed

If I understand correctly, your patch would disabled all JavaScript on all of https://tails.boum.org/ by default.

For example, would this break the collapsable section we have on the download page?

As part of our work on the Installation Assistant we've written down our position regarding JavaScript (see /blueprint/bootstrapping/assistant.html#index7h1). And I would find it be a bit sad to prevent ourselves from using any kind of JS on all of our website, while it seems like the problem here would be solved by disabling JS on the homepage only (/news).

The notes from the meeting are unclear about that, but our blueprint is more explicit regarding this.

#23 Updated by intrigeri about 3 years ago

  • QA Check changed from Info Needed to Dev Needed

If I understand correctly, your patch would disabled all JavaScript on all of https://tails.boum.org/ by default.

Right.

For example, would this break the collapsable section we have on the download page?

Oops, indeed it does! Good catch. I didn't remember we were already using JS on our website.

As part of our work on the Installation Assistant we've written down our position regarding JavaScript (see /blueprint/bootstrapping/assistant.html#index7h1). And I would find it be a bit sad to prevent ourselves from using any kind of JS on all of our website,

Indeed, sorry I forgot that :/

while it seems like the problem here would be solved by disabling JS on the homepage only (/news).

I'll try do to that. Now that I think of it, Giorgio has explained me a few months ago how to do something like that (with a whitelist approach instead of a blacklist one, though -- I think that's acceptable, but a blacklist approach would be nicer, in that doc writers may want toggle directives they add to work in Tails without having to patch it and wait for next release). Tested, doesn't work for me => asked Giorgio for info.

#24 Updated by intrigeri about 3 years ago

  • % Done changed from 10 to 20

intrigeri wrote:

If I understand correctly, your patch would disabled all JavaScript on all of https://tails.boum.org/ by default.

Right.

For example, would this break the collapsable section we have on the download page?

Oops, indeed it does! Good catch. I didn't remember we were already using JS on our website.

As part of our work on the Installation Assistant we've written down our position regarding JavaScript (see /blueprint/bootstrapping/assistant.html#index7h1). And I would find it be a bit sad to prevent ourselves from using any kind of JS on all of our website,

Indeed, sorry I forgot that :/

da579e6 fixes that with a blacklist approach. Random manual testing passes, will now run the automatic test suite.

#25 Updated by intrigeri about 3 years ago

  • Assignee deleted (intrigeri)
  • % Done changed from 20 to 50
  • QA Check changed from Dev Needed to Ready for QA

Passes features/encryption.feature features/torified_browsing.feature features/unsafe_browser.feature features/windows_camouflage.feature

#26 Updated by intrigeri about 3 years ago

Beware, I rewrote the history of this branch as the only change it carried was going to be reverted anyway.

#27 Updated by anonym about 3 years ago

  • Assignee set to intrigeri
  • QA Check changed from Ready for QA to Info Needed

If our web server is compromised, the attacker could redirect us to another page (possibly on another domain) under its control that serves the attack, so the blacklist approach seems pointless to me. In fact, can't the attacker just serve the JavaScript from another domain without a redirect? I thought this was why the blacklist approach in NoScript is pretty much worthless. If I'm right, I don't thing there's any point in merging this branch.

It seems to me, again, that the issue is that there is a specific site that we automatically connect to with the browser.

#28 Updated by intrigeri about 3 years ago

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

#29 Updated by intrigeri about 3 years ago

If our web server is compromised, the attacker could redirect us to another page (possibly on another domain) under its control that serves the attack, so the blacklist approach seems pointless to me. In fact, can't the attacker just serve the JavaScript from another domain without a redirect?

Yes:

  • if the attacker can reconfigure the webserver, then they can definitely serve whatever JavaScript they want;
  • if the attacker got write access to our website only:
    • the redirect attack you're describing works, but only because we're allowing rewrite rules in htaccess; we could have this credential removed, and ask to do such changes each time we need it, but it would be a bit painful;
    • not sure if JS from another domain would work (http://ikiwiki.info/plugins/htmlscrubber/ hopefully prevents such attacks, as long as we don't disable this defense in depth feature (#10299)).

I thought this was why the blacklist approach in NoScript is pretty much worthless. If I'm right, I don't thing there's any point in merging this branch.

It could be made more useful (see above for what changes we would need) but the effort is probably not worth it. Better come up with a real solution, that is:

It seems to me, again, that the issue is that there is a specific site that we automatically connect to with the browser.

Yes. Sorry for having wasted our collective time on it.

What we need is to think about our notification mechanisms: we have three partially overlapping systems (the browser homepage, the security notifications, and the Upgrader ones) that convey similar info in totally different ways. Some UX folks should sit down with Tails code/security people and think through what is the cheapest way to fix this security issue, at least without harming UX, and quite possibly improving it along the way.

#30 Updated by intrigeri about 3 years ago

  • Subject changed from Mitigate potential security issues caused by using the Tails website as the browser homepage to Mitigate security issues caused by using the Tails website as the browser homepage
  • Assignee deleted (intrigeri)
  • Target version deleted (Tails_1.7)
  • QA Check deleted (Info Needed)
  • Type of work changed from Research to User interface design

#31 Updated by u over 1 year ago

  • % Done changed from 50 to 0

intrigeri wrote:

What we need is to think about our notification mechanisms: we have three partially overlapping systems (the browser homepage, the security notifications, and the Upgrader ones) that convey similar info in totally different ways. Some UX folks should sit down with Tails code/security people and think through what is the cheapest way to fix this security issue, at least without harming UX, and quite possibly improving it along the way.

As this still seems to be the case when opening the browser, we might want to get back to finding a solution to this.

Also available in: Atom PDF