16

Recently, while using the Tor Browser, NoScript popped up the following warning when I opened a stack overflow link in a new tab from duckduckgo:

NoScript warning

Potential Identity Leak

You are about to load a page from stackoverflow.com. If you are a stackoverflow.com logged-in user, information about your identity might be acquired by duckduckgo.com

Now, as far as I know, when I click on a Stack Overflow link, Stack Overflow won't normally send any information back to duckduckgo. So how is this identity leak/de-anonymization attack supposed to work?

4
  • 2
    I believe that when you click a search result link on DDG, they somehow add JavaScript to the destination page from the origin "improving.duckduckgo.com". Not sure I have this description exactly right but I see this happen frequently and they explain more about it here. Aug 12 at 12:48
  • 1
    @TomBrossman Unless you are using DuckDuckGo's own browser or their extension, that should not be possible.
    – nobody
    Aug 12 at 16:29
  • 1
    @TomBrossman Unless the destination page also belongs to DuckDuckGo, this is impossible by design. Unless, of course, it is done via an extension or custom browser. Even in those cases, DuckDuckGo’s own explanation does not seem to mention adding JavaScript to non-DuckDuckGo pages. Aug 13 at 7:47
  • I can confirm this happens on pages unrelated to DDG. I do wonder why, but I just have my uBlock Origin globally blocking DDG except on DDG. I always see DDG scripts blocked on pages I reached from DDG.
    – Grault
    Aug 14 at 1:55

1 Answer 1

20

So after some digging into NoScript's settings, I found some settings for something called "Cross-tab identity leak protection". Googling this led to a tor project issue Targeted Deanonymization via the Cache Side Channel. This seems to be a recently-added feature of NoScript intended to protect against a new de-anonymization attack. However, the attack seems to be of concern only for a somewhat niche threat model.

The attack relies on a cache-timing side channel, and the ability to share a resource with only a specific user on websites like Twitter, Google etc. to uniquely identify a target. From the website of said attack:

The attack builds on a leaky resource attack by using CPU cache side channels instead of cross-site leaks. In this way, the range of attack scenarios (i.e., affected browsers and resource-sharing services) is considerably larger.

The attack consists of two phases, setup and execution. In the setup phase, the attacker uploads a resource to a resource-sharing service, and then binds it to the victim’s identity. There are two approaches to perform this binding. In the sharing-based approach, the attacker privately shares the resource with the target (e.g., by using the victim’s email address or user ID with the service). In the blocking-based approach, the attacker makes the resource public, and then blocks the target from viewing any resources owned by the attacker. Next, the attacker embeds this resource into an attacker-controlled webpage.

In the execution phase, the attacker causes the target to visit the attack page (steps 1 and 2). As the target’s browser renders the page, it makes a cross-site request for the embedded resource to the sharing service (steps 3 and 4), passing the user’s authentication cookies. The response of the sharing website to this request depends on the target’s identity. With the sharing-based approach, the response to this cross-site request contains the shared resource if the user is the target, and an error otherwise (step 5). With the blocking-based approach, the opposite happens – the response contains an error for the blocked target, and the shared resource for other users.

In the final step of the attack, the attacker needs to discover whether the shared resource was loaded. The Same-Origin policy prevents the attacker from directly reading out the cross-origin response. However, by using a browser-based CPU cache side channel, the attacker is able to learn if the resource has been loaded or not. Specifically, the attacker page uses JavaScript to measure the contention to the CPU cache (step 6) – depending on whether the resource is being loaded or not, the contention to access the CPU cache will have distinct patterns.

5
  • 2
    Did you really “Google” the setting name? Or did you “DuckDuckGo” it? Aug 12 at 7:16
  • 5
    @BrianDrake I did both, Google ended up being to be more helpful
    – nobody
    Aug 12 at 9:44
  • 4
    @nobody you may know, but you can use Google via duckduckgo. Just add !g to your search terms, e.g. noscript block settings !g.
    – BruceWayne
    Aug 12 at 15:52
  • 4
    @BruceWayne all this does is redirect you to google Aug 12 at 17:48
  • 3
    @dcom-launch correct but DDG strips all the personally identifying stuff/trackers/etc for the request.
    – BruceWayne
    Aug 12 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.