Opened 7 years ago

Closed 7 years ago

#5715 closed defect (fixed)

"New Identity" has cache race conditions that temporarily allow evercookies

Reported by: guiseppe Owned by: mikeperry
Priority: Very High Milestone:
Component: TorBrowserButton Version:
Severity: Keywords: MikePerry201205
Cc: g.koppen@… Actual Points: 3
Parent ID: Points: 3
Reviewer: Sponsor:

Description

The TorBrowser is not defending against evercookies.

By pressing the TorBrowserButton "New Identity", the evercookies set by samy.pl/evercookie seem to be cleared, but they are restorable.

This affects the following types of evercookies:

cacheData mechanism
etag mechanism
pngData mechanism
windowData mechanism
cookieData mechanism

That is a critical behavior because of linkability between different TorBrowser sessions.

If the TorBrowser is completely closed and then reopened, the evercookies seem to be really deleted according to Samy's testing page.

Please check this. Thanks!

Child Tickets

Change History (11)

comment:1 Changed 7 years ago by mikeperry

Keywords: MikePerry201205 added; evercookie linkability removed

Wow. This is just an awesomely bad regression. Thanks for testing. I'm still not sure how this data is persisting. According to about:cache, "New Identity" is properly clearing all cache entries..

In fact, if I wait a minute or two, or do something else between samy.pl visits, it is in fact unable to regenerate my evercookies.. Sounds like the cache picked up some fun race conditions while we weren't looking...

comment:2 Changed 7 years ago by gk

Cc: g.koppen@… added

comment:3 Changed 7 years ago by mikeperry

Summary: TorBrowser not defending against evercookies despite of TorBrowserButton "New Identity""New Identity" has cache race conditions that temporarily allow evercookies

Ok, I think I got a fix for this. There's two parts: In TorBrowserButton, we now explicitly clear the image cache. In Tor Browser, I patched nsCacheService::EvictEntires to include an atomic call to wipe the "doomed" cache entry list.

These two combined appear to eliminate the race condition. I'm unable to get the evercookies to persist on my dev build with these changes. The exact mechanics of the "doomed" list expiry are still a bit fuzzy to me, though. I just sort of cargo-culted the expiry code from the cache service shutdown routine...

Also, there is a very suspicious comment in the ImageCache code that seems to indicate it may not be obeying our CacheKey isolation.

gk - if you have spare cycles, could you maybe test third party images and make sure the same image url still gets 200 load requests from two different url bar domains?

comment:4 in reply to:  3 ; Changed 7 years ago by gk

gk - if you have spare cycles, could you maybe test third party images and make sure the same image url still gets 200 load requests from two different url bar domains?

Sure. Do you want me to test with JonDoFox as is? Or with TBB including your fixes? Or... The TBB testing could take some time as I do not have a TBB build environment yet.

comment:5 in reply to:  4 ; Changed 7 years ago by mikeperry

Replying to gk:

gk - if you have spare cycles, could you maybe test third party images and make sure the same image url still gets 200 load requests from two different url bar domains?

Sure. Do you want me to test with JonDoFox as is? Or with TBB including your fixes? Or... The TBB testing could take some time as I do not have a TBB build environment yet.

My fixes above are only relevant to New Identity. Do you make use of https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0004-Add-a-string-based-cacheKey.patch in JonDos? If so, test your per-tab isolation or whatever uses it with images. https://encrypted.google.com/images/srpr/logo3w.png seems like a fine image to source from two tabs. If it actually loads in both tabs, it's not cached. Tools->Web Developer->Web Console should be sufficient. I am still looking for an official machine to hold random tests like this. :/

comment:6 in reply to:  5 Changed 7 years ago by gk

Replying to mikeperry:

Replying to gk:

gk - if you have spare cycles, could you maybe test third party images and make sure the same image url still gets 200 load requests from two different url bar domains?

Sure. Do you want me to test with JonDoFox as is? Or with TBB including your fixes? Or... The TBB testing could take some time as I do not have a TBB build environment yet.

My fixes above are only relevant to New Identity. Do you make use of https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0004-Add-a-string-based-cacheKey.patch in JonDos?

Not yet. But I have an alpha version of JonDoBrowser and could apply the patch to it.

If so, test your per-tab isolation or whatever uses it with images. https://encrypted.google.com/images/srpr/logo3w.png seems like a fine image to source from two tabs. If it actually loads in both tabs, it's not cached. Tools->Web Developer->Web Console should be sufficient.

Ok. I'll see what i can do.

comment:7 Changed 7 years ago by mikeperry

Actual Points: 3
Points: 3
Resolution: fixed
Status: newclosed

These fixes have been pushed to maint-2.2 of Tor Browser, and master of Torbutton.

gk - I've filed #5742 for the test.

comment:8 Changed 7 years ago by cypherpunks

Mike!

I've heard that the TorBrowser has been vulnerable to evercookies for about three years.

Could you please give a short explanation to which extent users were exposed during that time to the threat of deanonymisation due to this bug recently fixed.

Maybe some users are screwed now because of these crazy evercookies..

comment:9 Changed 7 years ago by mikeperry

I tested samy.pl repeatedly during the toggle model development, and again with New Identity development. We've had regressions on it before, and we'll probably have them again. As far as I know, it wasn't always broken, though. Also, in this case it was a race condition where evercookies only persisted for a short time after "New Identity", not a total break (at least with my testing on Linux). If some platforms were totally broken broken, please let me know.

See #3846 and #5292 and consider helping out with testing new builds to prevent this from happening in the future.

comment:10 Changed 7 years ago by cypherpunks

Resolution: fixed
Status: closedreopened

Bad news from the evercookie frontierline.

I have tested the new TBB (2.2.35-12).
'samy.pl/evercookie' is still able to recover evercookies.

Procedure to reproduce this:
Go on the testing page, create an evercookie, click "New Identity", then return on the site and reactivate the evercookie.
You will see: linkability is back!

comment:11 Changed 7 years ago by mikeperry

Resolution: fixed
Status: reopenedclosed

Please read the comments closely. This requires Torbutton 1.4.6pre2 to get the update to New Identity to clear the PNG vector. There's a copy of the Torbutton that fixes it in the attachment in #5710. You need both the Torbutton update *and* the TBB patch for this to be fixed.

I verified *again*, and with the Torbutton 1.4.6pre2 xpi in #5710, it is in fact fixed.

Please reopen if not, and specify your platform.

Note: See TracTickets for help on using tickets.