8 ms·

Preventing Pool-Party Attacks

114 points by decrypt 5y ago

zaltekk 5y ago
Here's the paper: https://arxiv.org/pdf/2112.06324.pdf https://arxiv.org/pdf/2112.06324.pdf
- akavel 5y ago
  The tl;dr: “Pool-party” attacks work by manipulating pools of browser resources which are limited (i.e., the browser restricts how many of the resource websites can open or consume) and unpartitioned (i.e., different contexts consume resources from the same pool). While the examples focused on in this work utilize limited-but-unpartitioned pools of network connections, browsers include many other limited-but-unpartitioned resource pools that could be similarly exploited, such as pools of file handles, subprocesses, or other resource handles. A “pool-party” attack occurs when parties operating in distinct contexts (contexts the user expects to be distinct and blinded from each other) intentionally consume and query the availability of the limited resources in a resource pool, to create a cross-context communication channel. Each context can then use the communication channel to pass an identifier, allowing each party to link the users behavior across the two contexts. We note again that most commonly the two contexts considered here are two different websites running in the same browser profile, but could also be the same (or different) websites running in different browser profiles.
  - formerly_proven 5y ago
    Uhm, cooperative cross-context channels are a dime a dozen just running on any CPU, nevermind in a browser. I don't see how this is interesting, or surprising. Modern computers are not MLS-style systems where it's supposed to be information-theoretically impossible to pass information unless permitted by a formal model.
    - infogulch 5y ago
      Is there no room for middle ground between "information theoretic formal proof" and "open the floodgates"? I don't run any MLS systems, so is my fate to just give up, drop my pants and take it?
      - formerly_proven 5y ago
        There is, you can for example use Qubes OS. That's pretty ergonomic and you get a reasonable amount of separation between stuff.
mlinksva 5y ago
The linked https://privacytests.org/ https://privacytests.org/ looks like a really useful aggregation/rundown/testing of privacy protecting features across browsers.
nojs 5y ago
I’m trying to understand the problem here. If the website you’re on has some javascript that’s executing side channel attacks to uniquely identify you, why couldn’t they just use other fingerprinting techniques?
- mlyle 5y ago
  Perhaps you have the other fingerprinting techniques locked down. Brave has a whole lot of anti-fingerprinting measures. So instead, this approach has different adversaries sharing the fractional information they've gathered about this user and collaborate to build a stronger profile to positively identify the user.
- sfink 5y ago
  I believe this is assuming that fingerprinting mitigations are good enough to prevent unique identification. If you can uniquely identify a user, you don't need any cross-context coordination. The problem as I understand it is when you have two separate contexts, neither of which can unique identify you by themselves, and they want to test whether you are in fact the same user and furthermore send information between each other. The two contexts are usually either (1) two different websites, or (2) two different browsing contexts (two profiles or one is a private browsing / incognito session) on one site. The two contexts have a server-side communication channel to coordinate the attack. The two together may still not be able to uniquely identify you, but that's not the attack -- they just want to learn if you're the same user. I haven't read the paper, but I imagine it to work like this: say you have a global maximum of 100 WebSocket connections allowed alive at once. Context 1 opens up WebSockets until opening a new one fails. Then it tells the other context "hey, watch this." Using a shared clock, it closes one of the sockets for 1 second, reopens one for 1 second, etc., producing a string of 1s and 0s. The other context reads this string by attempting to open a socket of its own for a millisecond before closing it. (This is all hypothetical, there are probably flaws all over this.) If the probe succeeds, that's a 0, else it's a 1. You pass across a randomly-generated UUID or something. If you're using separate profiles, the advertiser (attacker) can now permanently remember that those profiles are actually the same person. You have a happy tracker, sad user. To defeat it, you need to partition the maximum limit, which means you either allow massive overcommitting, or you artificially restrict everything to a small value. It looks like they're arguing for overcommitting, using the argument that this will cause the attack to degrade the user's experience enough that they'll stop using the site, which means it'll stop being used. (To mitigate it, it seems like you could slow down the cross-context resource accounting, to make the bit rate too slow to be useful? But it probably doesn't take many bits.)
namelessoracle 5y ago
Is it bad that I thought at first from the title it was referring to the reports a few years ago of gangs attacking rival gang members at the local pool? (sense its a location they are presumably off guard and wouldnt have access to weapons to defend themself)
- fuzzer37 5y ago
  I was thinking it had to do with the Habbo Hotel pool raids, personally.
- PeterHolzwarth 5y ago
  It is not bad that you thought that. But it is bad that you then decided to add a post to that effect.
annoyingnoob 5y ago
Don't forget that Brave is the product of an advertising network and their goal is to increase use of Brave to push more ads.
- pineconewarrior 5y ago
  So is Chrome. This doesn't diminish the value of security research and subsequent improvements by either. I'll stick to Firefox anyway :)
  - encryptluks2 5y ago
    Note that Firefox reports quite a lot of information by default and just like Chromium, you should look into using policies to prevent that.
    - pineconewarrior 5y ago
      Indeed - Privacy Badger, uBlock Origin (with some additional lists), Multi-Account Containers, and some settings adjustments are in place for me :) On top of network-level filtering!
- ThunderSizzle 5y ago
  I'll take Brave over Mozilla or Google right now. Size matters.
- rglullis 5y ago
  Ads that are opt-in, do not send data to third-parties and do not work as a monetization strategy for low-quality content publishers? How I wish all advertising networks worked like that.
  - annoyingnoob 5y ago
    > do not send data to third-parties and do not work as a monetization strategy for low-quality content publishers Oh, yeah? They may aggregate or otherwise anonymize data but there is absolutely reporting to advertisers. https://github.com/brave/brave-browser/wiki/Security-and-privacy-model-for-ad-confirmations https://github.com/brave/brave-browser/wiki/Security-and-pri... They call it 'ad confirmations' and spend a lot of time trying to convince you that its all private. Its not all private to Brave itself, which is an advertising network.
akersten 5y ago
It's unclear- do these attacks require you to have the hostile site(s) open simultaneously in both private and non-private tabs? Seems like it would, for the resources to stay allocated. If that's the case, it's kind of a "hm, neat, fix the partitioning" to me rather than something that needs its own name and hoopla.
- downWidOutaFite 5y ago
  Or the same ad network.
ljhsiung 5y ago
I did some digging. To me it was rather unclear about the impact of this. Furthermore, it definitely just feels like a recategorization/relabelling on Brave's part to get some brownie points. Not that it's not interesting, but I feel it's just a new name but old concept. This [0] is a 1 year old referenced wiki page in the article, which itself is a reference to a 3 year old Chromium bug [1]. The issue is, as some commenters mentioned, one process in another tab hogging all the sockets can make determine the timing on a new socket that is requested. If the socket's timing is data dependent, then you can infer what the data is. That's basically XS-search attacks [2]. [1] uses the example of 'https://mail.yahoo.com/d/search/keyword= https://mail.yahoo.com/d/search/keyword=', where the keyword "Amazon Purchase" consumes a socket and takes a longer amount of time due to our socket hogging vs. if we didn't hog it. This timing dependency lets us know across tabs that the victim buys stuff off Amazon. In some cases, you can deterministically force the victim to execute this search query, and thus, the side channel. [0]: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/ https://xsleaks.dev/docs/attacks/timing-attacks/connection-p... [1]: https://bugs.chromium.org/p/chromium/issues/detail?id=843157 https://bugs.chromium.org/p/chromium/issues/detail?id=843157 [2]: https://xsleaks.dev/ https://xsleaks.dev/
- chalst 5y ago
  > Furthermore, it definitely just feels like a recategorization/relabelling on Brave's part to get some brownie points. Not that it's not interesting, but I feel it's just a new name but old concept. More generously, I'd say they were giving the matter a more accessible name to raise consciousness about it and because they intend to do significant future work addressing it. There is a marketing angle to this: they might then claim to be the most private browser on this basis. However, given they are cooperating with other browser dev teams on this, if the danger of bypassing anti-fingerprinting measures is as serious as they say, this seems quite legitimate.

114 points by decrypt 5y ago

zaltekk 5y ago

Here's the paper: https://arxiv.org/pdf/2112.06324.pdf https://arxiv.org/pdf/2112.06324.pdf

akavel 5y ago
The tl;dr: “Pool-party” attacks work by manipulating pools of browser resources which are limited (i.e., the browser restricts how many of the resource websites can open or consume) and unpartitioned (i.e., different contexts consume resources from the same pool). While the examples focused on in this work utilize limited-but-unpartitioned pools of network connections, browsers include many other limited-but-unpartitioned resource pools that could be similarly exploited, such as pools of file handles, subprocesses, or other resource handles. A “pool-party” attack occurs when parties operating in distinct contexts (contexts the user expects to be distinct and blinded from each other) intentionally consume and query the availability of the limited resources in a resource pool, to create a cross-context communication channel. Each context can then use the communication channel to pass an identifier, allowing each party to link the users behavior across the two contexts. We note again that most commonly the two contexts considered here are two different websites running in the same browser profile, but could also be the same (or different) websites running in different browser profiles.
- formerly_proven 5y ago
  Uhm, cooperative cross-context channels are a dime a dozen just running on any CPU, nevermind in a browser. I don't see how this is interesting, or surprising. Modern computers are not MLS-style systems where it's supposed to be information-theoretically impossible to pass information unless permitted by a formal model.
  - infogulch 5y ago
    Is there no room for middle ground between "information theoretic formal proof" and "open the floodgates"? I don't run any MLS systems, so is my fate to just give up, drop my pants and take it?
    - formerly_proven 5y ago
      There is, you can for example use Qubes OS. That's pretty ergonomic and you get a reasonable amount of separation between stuff.

mlinksva 5y ago

The linked https://privacytests.org/ https://privacytests.org/ looks like a really useful aggregation/rundown/testing of privacy protecting features across browsers.

nojs 5y ago

I’m trying to understand the problem here. If the website you’re on has some javascript that’s executing side channel attacks to uniquely identify you, why couldn’t they just use other fingerprinting techniques?

mlyle 5y ago
Perhaps you have the other fingerprinting techniques locked down. Brave has a whole lot of anti-fingerprinting measures. So instead, this approach has different adversaries sharing the fractional information they've gathered about this user and collaborate to build a stronger profile to positively identify the user.
sfink 5y ago
I believe this is assuming that fingerprinting mitigations are good enough to prevent unique identification. If you can uniquely identify a user, you don't need any cross-context coordination. The problem as I understand it is when you have two separate contexts, neither of which can unique identify you by themselves, and they want to test whether you are in fact the same user and furthermore send information between each other. The two contexts are usually either (1) two different websites, or (2) two different browsing contexts (two profiles or one is a private browsing / incognito session) on one site. The two contexts have a server-side communication channel to coordinate the attack. The two together may still not be able to uniquely identify you, but that's not the attack -- they just want to learn if you're the same user. I haven't read the paper, but I imagine it to work like this: say you have a global maximum of 100 WebSocket connections allowed alive at once. Context 1 opens up WebSockets until opening a new one fails. Then it tells the other context "hey, watch this." Using a shared clock, it closes one of the sockets for 1 second, reopens one for 1 second, etc., producing a string of 1s and 0s. The other context reads this string by attempting to open a socket of its own for a millisecond before closing it. (This is all hypothetical, there are probably flaws all over this.) If the probe succeeds, that's a 0, else it's a 1. You pass across a randomly-generated UUID or something. If you're using separate profiles, the advertiser (attacker) can now permanently remember that those profiles are actually the same person. You have a happy tracker, sad user. To defeat it, you need to partition the maximum limit, which means you either allow massive overcommitting, or you artificially restrict everything to a small value. It looks like they're arguing for overcommitting, using the argument that this will cause the attack to degrade the user's experience enough that they'll stop using the site, which means it'll stop being used. (To mitigate it, it seems like you could slow down the cross-context resource accounting, to make the bit rate too slow to be useful? But it probably doesn't take many bits.)

namelessoracle 5y ago

Is it bad that I thought at first from the title it was referring to the reports a few years ago of gangs attacking rival gang members at the local pool? (sense its a location they are presumably off guard and wouldnt have access to weapons to defend themself)

fuzzer37 5y ago
I was thinking it had to do with the Habbo Hotel pool raids, personally.
PeterHolzwarth 5y ago
It is not bad that you thought that. But it is bad that you then decided to add a post to that effect.

annoyingnoob 5y ago

Don't forget that Brave is the product of an advertising network and their goal is to increase use of Brave to push more ads.

pineconewarrior 5y ago
So is Chrome. This doesn't diminish the value of security research and subsequent improvements by either. I'll stick to Firefox anyway :)
- encryptluks2 5y ago
  Note that Firefox reports quite a lot of information by default and just like Chromium, you should look into using policies to prevent that.
  - pineconewarrior 5y ago
    Indeed - Privacy Badger, uBlock Origin (with some additional lists), Multi-Account Containers, and some settings adjustments are in place for me :) On top of network-level filtering!
ThunderSizzle 5y ago
I'll take Brave over Mozilla or Google right now. Size matters.
rglullis 5y ago
Ads that are opt-in, do not send data to third-parties and do not work as a monetization strategy for low-quality content publishers? How I wish all advertising networks worked like that.
- annoyingnoob 5y ago
  > do not send data to third-parties and do not work as a monetization strategy for low-quality content publishers Oh, yeah? They may aggregate or otherwise anonymize data but there is absolutely reporting to advertisers. https://github.com/brave/brave-browser/wiki/Security-and-privacy-model-for-ad-confirmations https://github.com/brave/brave-browser/wiki/Security-and-pri... They call it 'ad confirmations' and spend a lot of time trying to convince you that its all private. Its not all private to Brave itself, which is an advertising network.

akersten 5y ago

It's unclear- do these attacks require you to have the hostile site(s) open simultaneously in both private and non-private tabs? Seems like it would, for the resources to stay allocated. If that's the case, it's kind of a "hm, neat, fix the partitioning" to me rather than something that needs its own name and hoopla.

downWidOutaFite 5y ago
Or the same ad network.

ljhsiung 5y ago

I did some digging. To me it was rather unclear about the impact of this. Furthermore, it definitely just feels like a recategorization/relabelling on Brave's part to get some brownie points. Not that it's not interesting, but I feel it's just a new name but old concept. This [0] is a 1 year old referenced wiki page in the article, which itself is a reference to a 3 year old Chromium bug [1]. The issue is, as some commenters mentioned, one process in another tab hogging all the sockets can make determine the timing on a new socket that is requested. If the socket's timing is data dependent, then you can infer what the data is. That's basically XS-search attacks [2]. [1] uses the example of 'https://mail.yahoo.com/d/search/keyword= https://mail.yahoo.com/d/search/keyword=', where the keyword "Amazon Purchase" consumes a socket and takes a longer amount of time due to our socket hogging vs. if we didn't hog it. This timing dependency lets us know across tabs that the victim buys stuff off Amazon. In some cases, you can deterministically force the victim to execute this search query, and thus, the side channel. [0]: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/ https://xsleaks.dev/docs/attacks/timing-attacks/connection-p... [1]: https://bugs.chromium.org/p/chromium/issues/detail?id=843157 https://bugs.chromium.org/p/chromium/issues/detail?id=843157 [2]: https://xsleaks.dev/ https://xsleaks.dev/

chalst 5y ago
> Furthermore, it definitely just feels like a recategorization/relabelling on Brave's part to get some brownie points. Not that it's not interesting, but I feel it's just a new name but old concept. More generously, I'd say they were giving the matter a more accessible name to raise consciousness about it and because they intend to do significant future work addressing it. There is a marketing angle to this: they might then claim to be the most private browser on this basis. However, given they are cooperating with other browser dev teams on this, if the danger of bypassing anti-fingerprinting measures is as serious as they say, this seems quite legitimate.