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

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!

Trac:
Username: guiseppe

added MikePerry201205 actualpoints::3 component::torbrowserbutton owner::mikeperry points::3 priority::very high reporter::guiseppe resolution::fixed status::closed type::defect labels

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...

Trac:
Keywords: evercookie, linkability deleted, MikePerry201205 added

Trac:
Cc: N/A to g.koppen@jondos.de

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?

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

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.

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. :/

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.

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

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

Trac:
Actualpoints: N/A to 3
Resolution: N/A to fixed
Points: N/A to 3
Status: new to closed

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..

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 (closed) and #5292 (moved) and consider helping out with testing new builds to prevent this from happening in the future.

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!

Trac:
Resolution: fixed to N/A
Status: closed to reopened

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 (closed). 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 (closed), it is in fact fixed.

Please reopen if not, and specify your platform.

Trac:
Resolution: N/A to fixed
Status: reopened to closed

closed

changed time estimate to 24h

added 24h of time spent

mentioned in issue #5742 (closed)

mentioned in issue #6386 (closed)

mentioned in issue #7637 (moved)

mentioned in issue #12620 (moved)

mentioned in issue tpo/applications/torbutton#7637 (moved)