1386461 - Don't reveal UI language in mozilla-driven & automatically accessed URLs

Status: RESOLVED WONTFIX

(Toolkit :: General, defect)

Description

[Reşat SABIQ (Reshat)]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170608105825

Steps to reproduce:

Some automatic requests made by Firefox reveal the UI locale even if user doesn't anything other than launching the app.[1]


Actual results:

[1] E.g.:
[exec] RequestAssistant (2017-08-01 17:43:29): profile-after-change...
a) [exec] RequestAssistant (2017-08-01 17:44:30): https://aus5.mozilla.org/update/3/GMP/54.0a2/20170511074736/Linux_x86_64-gcc3/en-US/aurora/Linux%204.8.0-53-generic%20(GTK%203.18.9%2Clibpulse%208.0.0)/default/default/update.xml
b) [exec] RequestAssistant (2017-08-01 17:46:00): https://versioncheck-bg.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id={16f796dd-a279-4548-9b3a-393d1eef31df}&version=0.8.3b1&maxAppVersion=*&status=userEnabled&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=54.0a2&appOS=Linux&appABI=x86_64-gcc3&locale=tr&currentAppVersion=54.0a2&updateType=112&compatMode=normal


Expected results:

There are requests a) & b) indicated above.

I believe it's worth the effort, to make a POST request & pass the locale in POST body, thus making it encrypted.

Comment 1

[Reşat SABIQ (Reshat)]

This could be considered a similar consideration to that of bug 55366.

Comment 2

[Reşat SABIQ (Reshat)]

What's revealed in b) is general.useragent.locale pref,
whereas in a) it seems to be the installed app's locale (not the current UI locale).

Comment 3

[:Gijs (out for now; he/him)]

The language is part of the querystring, and because the request happens over https, it is already encrypted. It doesn't need to be in the post body for this. See e.g. https://stackoverflow.com/questions/2629222/are-querystring-parameters-secure-in-https-http-ssl .

Comment 4

[Robert Strong (they/them - no direct email)]

Gijs, the aus server doesn't use a querystring for these. To verify open about:config and type aus. You'll find
app.update.url
extensions.systemAddon.update.url
media.gmp-manager.url

all send the locale info without using a querystring.

Reopening due to this.

Moving to toolkit -> general since this is a general problem and not just app update.

Adding rhelmer since he owns the code that uses the last 2 urls.

dveditz, would you evaluate whether this bug should be addressed or send it to someone else more appropriate? Thanks!

Comment 5

[:Gijs (out for now; he/him)]

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #4)
> Gijs, the aus server doesn't use a querystring for these. To verify open
> about:config and type aus. You'll find
> app.update.url
> extensions.systemAddon.update.url
> media.gmp-manager.url
> 
> all send the locale info without using a querystring.

Ah, I was confused because the second URL from comment #0 uses a query string. Looks like that's an AMO update check for installed add-ons or something?

In any case, it doesn't really matter - the entire GET URL is encrypted given it's https. I don't see the point of switching to POST (but then, comment #0 already doesn't really have any details of what it's supposed to protect against).

Comment 6

[Reşat SABIQ (Reshat)]

(In reply to :Gijs from comment #5)
> In any case, it doesn't really matter - the entire GET URL is encrypted
> given it's https. 
At the very least, there is a vulnerability at DNS resolution (request/response) phase. On top of that server logs, browser history, etc.

> I don't see the point of switching to POST (but then,
> comment #0 already doesn't really have any details of what it's supposed to
> protect against).
Please see comment #1.

Comment 7

[:Gijs (out for now; he/him)]

(In reply to Reşat SABIQ (Reshat) from comment #6)
> (In reply to :Gijs from comment #5)
> > In any case, it doesn't really matter - the entire GET URL is encrypted
> > given it's https. 
> At the very least, there is a vulnerability at DNS resolution
> (request/response) phase.

The DNS request won't have the entire URI, so it doesn't include the language code either. That's part of the point of https, that people in the middle don't see the request content apart from the hostname.

> On top of that server logs,

The server could store the POST body just as well. If you don't trust the server (which in this case is mozilla's) it's not clear to me why you would first have downloaded executable software from it and run it on your machine.

> browser history,

If I have access to your browser history, I can just check the UI language in the browser itself, right?

> etc.

It's still really not clear to me what you think the risk is here. Security/privacy bugs generally have some kind of explanation of what the (perceived) threat is, and this bug does not.

> > I don't see the point of switching to POST (but then,
> > comment #0 already doesn't really have any details of what it's supposed to
> > protect against).
> Please see comment #1.

The bug you mentioned is about exposing the UI locale to a site you don't trust. Presumably you trust mozilla.org or you wouldn't have downloaded Firefox off it. The app update server needs the locale in order to know what updates to give you (presumably if you run Firefox in French, you want your next version of Firefox in French, too). Suggesting a change in transport methodology for the same content (UI locale) is different to what the bug in comment #1 fixed (which is use value A instead of value B for some API - changing the content, not the transport methodology), and as a result I don't think just pointing to the other bug offers good reasons for why something should change here.

Comment 8

[Daniel Veditz [:dveditz]]

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #4)
> dveditz, would you evaluate whether this bug should be addressed or send it
> to someone else more appropriate? Thanks!

I agree with Gijs:

* network watchers only know you went to aus5 or versioncheck. HTTPS protects the URL path and parameters as much as it does the request body. We are only revealing the language to Mozilla, which is required to fulfill the request correctly.

* a network MITM (for example, corporate security/compliance monitoring) can see the URL path, but they can also see any POST body so that won't help against this kind of attacker.

* the URL path is not stored in your browser history because this is an internal request. But someone who can see your history files can also see which version of Firefox is installed.

* the path will be stored in the networking cache, but if you can inspect the cache you can also see which Firefox is installed.

Comment 9

[Reşat SABIQ (Reshat)]

(In reply to Daniel Veditz [:dveditz] from comment #8)
> * a network MITM (for example, corporate security/compliance monitoring) can
> see the URL path, but they can also see any POST body so that won't help
> against this kind of attacker.
You mean such MITM knows everything about the handshake & that allows them to also see the POST body? Even if that's true (i'm not that familiar w/ these details), don't they at least have to work on it, rather than just seeing it w/o much effort at all?