Unpatched browser weaknesses can be exploited to track millions of Web users

[Gary]

Does this affect current or future versions of Firefox?

Unpatched browser weaknesses can be exploited to track Web users
http://arstechnica.com/security/2015/10/unpatched-browser-weaknesses-can-be-exploited-to-track-millions-of-web-users/

[WaltS48]

I believe the article said future.

I guess the alternative is to keep things the way they are, and allow
downgrade attacks and cookie hijacking, which HSTS is supposed to
protect against, and impersonation of web sites by attackers using
mis-issued or otherwise fraudulent certificates, which HPKP is supposed
to protect against.

--
Linux Mint 17.2 "Rafaela" | KDE 4.14.2 | Thunderbird 44.0a1 (Daily)
You don't need zero-days when machines wherever are packed with old-days.
Go Bucs! (next season) Go Pens! Go Sabres! Go Pitt!
[Visit Pittsburgh]<http://www.visitpittsburgh.com/>
[Coexist · Understanding Across Divides]<https://www.coexist.org/>

[Ralph Fox]

Have a read of http://www.ghacks.net/2015/10/16/how-to-prevent-hsts-tracking-in-firefox/

(dated 12 days before the arstechnica article)


--
Kind regards
Ralph

[Gary]

On Thu, 29 Oct 2015 08:34:40 +1300, Ralph Fox wrote:

> Have a read of http://www.ghacks.net/2015/10/16/how-to-prevent-hsts-tracking-in-firefox/

Nice find!

It says..."Firefox saves HSTS information to the file
SiteSecurityServiceState.txt
which you find in the root of your Firefox profile folder."

Worse, it says..."Unlike cookies, HSTS offers no whitelist or blacklist approach.
The feature is enabled by default and there appears to be
no preference to disable it."


I have two of those HSTS files:
$ locate SiteSecurityServiceState.txt
=> $HOME/.mozilla/firefox/w73ngtpl.default/SiteSecurityServiceState.txt
=> /usr/local/sbin/tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default/SiteSecurityServiceState.txt

Here is what is in the first one:
$ cat SiteSecurityServiceState.txt
noscript.net:HSTS 0 16734 1603577974500,1,0
support.cdn.mozilla.net:HPKP 0 16734 1447197899843,1,0,r/mIkG3eEpVdm+u/ko/cwxzONp4ar3TyHIlByibiA5E=WoiWAqKBEVe8ihaBciRSC8ELseoTS9VwUGOIud4PB18=
services.addons.mozilla.org:HSTS 0 16734 1477437775780,1,0
support.mozilla.org:HSTS 0 16734 1477437898840,1,0
addons.mozilla.org:HSTS 0 16734 1477433958099,1,0
secure.informaction.com:HSTS 0 16734 1603582858985,1,0
addons.cdn.mozilla.net:HSTS 0 16734 1477433426259,1,0
blocklist.addons.mozilla.org:HSTS 0 16734 1477434089911,1,0
support.mozilla.org:HPKP 0 16734 1447197898841,1,0,r/mIkG3eEpVdm+u/ko/cwxzONp4ar3TyHIlByibiA5E=WoiWAqKBEVe8ihaBciRSC8ELseoTS9VwUGOIud4PB18=

They say the solution is to launch Firefox in private browsing mode:
"To launch Firefox in private browsing mode, use the shortcut
Ctrl-Shift-P, or hit the Alt-key and select File > New Private Window."

They seem to suggest we periodically wipe out that file:
echo ' ' >/SiteSecurityServiceState.txt
And that we make the file read only.

I'll add that to a script when I click on the Firefox icon.
What else would you suggest?

[VanguardLH]

Firefox 40.0.3
visited the sniffly page

Sites that I've visited: blank
Sites that I've probably not visited: dozens (well billions but they
can't list them all)

Says "HTTPS Everywhere for best results." Don't have that. After
looking into that add-on, all it does is provide a whitelist of known
sites where HTTPS alternative connects are available. It doesn't
actually test if an HTTPS version of the page is available and usable.

The radicalresearch test page gives me the same ID in each of their test
scenarios except when loading Firefox in its private mode. I have
Firefox configured to delete all its history on exit:

Browsing & Download History
Active Logins
Form & Search History
Cookies
Cache
Saved Passwords (plus passwords are not configured to get saved)
Offline Website Data (DOM Storage or localstorage)

are all selected to purge on Firefox's exit. I did not have Site
Preferences selected (to purge on exit). When I included purging of
Site Preferences on exit of Firefox, each new load of Firefox gave me a
different ID at the radicalresearch test page.

I also noticed that after I exit Firefox (with Site Preferences NOT
purged on exit) and using CCleaner to wipe Firefox data that the next
load of Firefox gave a different ID at the radicalresearch test page.

So either using CCleaner or purging Site Preferences on exit gave me a
different ID each time I loaded Firefox and visited the radicalresearch
test page. That was true over several tests.

Peculiarly in CCleaner, the Firefox settings did *not* have Site
Preferences included for cleanup. I then deselected all types of data
for CCleaner to delete for Firefox. The ID remained the same on each
revisit of the radicalresearch test page for a fresh load of Firefox. I
enabled only 1 of CCleaner's data types to delete for Firefox.
Eventually I found just the "cookies" data type deleted by CCleaner for
Firefox eliminated the constant ID at radicalresearch. I have Firefox
configured to purge cookies on exit. There are no exceptions for
cookies so all are supposed to get deleted on exit.

While CCleaner was deleting the Firefox data in its "cookies" data type,
I had to select Site Preferences for purge on Firefox exit to eliminate
the constant ID at radicalresearch. When I open Firefox (homepage is
about:blank) and go to Options -> Privacy to show cookies, none are
listed. After visiting the radicalresearch test page, there are 2
cookies for radicalresearch.co.uk. I exit Firefox, it purges its
cookies, I reload Firefox, and the cookies list is empty. So, according
to Firefox's cookie lister, there are no cookies retained after exiting
Firefox. Those were per-session cookies so they can't be what kept the
constant ID across web browser sessions. Seems CCleaner's definition of
"cookies" goes beyond what Mozilla's defines as cookies.

So I could select Site Preferences to purge on exit from Firefox or I
can remember to run CCleaner after a Firefox session to purge more than
just the .txt cookies.

This is what Mozilla give for help on the Site Preferences option:

Site Preferences: Site-specific preferences, including the saved zoom
level for sites, character encoding, and the permissions for sites
(like pop-up blocker exceptions) described in the _Page Info window_.

The _Page Info window_ link talks about clicking on the "Site Identity
Button" at the left end of the address bar which can be a globe,
triangle or padlock icon. Then click on the More Info button. Under
the Permissions tab, I don't see anything unusual there. "Maintain
Offline Storage" is set to Default. DOM Storage is enabled (so sites
can store data there during a browser session) but "Offline Website
Data" (DOM Storage) is configured to get purged on Firefox's exit.
Other than this list of permissions for the site, I don't know what else
that Site Preferences might include. So Mozilla's help page about what
is Site Preferences is incomplete.

I do know that, for example, gets remembered for a site between web
browser sessions. That way, I don't have to keep changing zoom when
revisiting a page that has overly small sized fonts. When I read
https://wiki.mozilla.org/Site-Specific_Preferences, nothing popped out
as obvious as a preference that would record an ID; however, there would
have to be some method of associating preferences stored in Firefox to
apply against a site to when the site got visited.

While CCleaner will eliminate the constant ID problem, that requires me
to remember running it after exiting Firefox. Nah. For now and so it
is automatic, I'll include Site Preferences to purge on Firefox's exit.
I lose some convenience but gain some privacy.

[Gary]

On Thu, 29 Oct 2015 01:12:28 -0500, VanguardLH wrote:

> The radicalresearch test page gives me the same ID in each of their test
> scenarios except when loading Firefox in its private mode. I have
> Firefox configured to delete all its history on exit:

I googled for where that test page was and found this:
http://www.explabs.com/test/

When I ran that test, it says in big red letters that I failed.
Is that the test page you ran?

[VanguardLH]

Nope. The Arstechnica article first talks about sniffing out where
you've been. Doesn't take much config in the web browser to eliminate
that. The sniffly web page also says where you probably haven't been.
Don't understand why that would be important as there is no way their
results page could list the billions of sites that I have not visited.

>From the Arstechnica article at:

http://arstechnica.com/security/2015/10/unpatched-browser-weaknesses-can-be-exploited-to-track-millions-of-web-users/

under the "Zombie cookies rise again", the HSTS means of assigning an ID
to you to track as you browse around really isn't due to a cookie but
authors try to wrap up several local storage technologies under one
term. In the sentence "Another abuses HSTS to create supercookies that
can track users browsing in privacy mode" and where its hyperlink points
to another article:

http://arstechnica.com/security/2015/01/browsing-in-privacy-mode-super-cookies-can-track-you-anyway/

That discusses the HSTS scheme of using a unique ID stored on your
computer to track your surfing. The RadicalResearch reference is to:

http://www.radicalresearch.co.uk/lab/hstssupercookies

By including Site Preferences in history purging on exit from Firefox,
you don't get a unique ID. You lose saving site preferences, like zoom
level when you last visited at a site, but you don't have to load
Firefox in its private mode all the time to avoid being tracked.

[»Q«]

In
<news:mailman.4973.144615907...@lists.mozilla.org>,

VanguardLH <V...@nguard.LH> wrote:

> The sniffly web page also says where you probably haven't been.
> Don't understand why that would be important as there is no way their
> results page could list the billions of sites that I have not visited.

The Sniffly PoC only tests for specific sites in history. With any
given site it tests for, there are only two possible outcomes,
"probably visited" and "probably not visited", so it puts each site
tested into one of those categories.