[HN Gopher] Preventing Pool-Party Attacks
___________________________________________________________________
Preventing Pool-Party Attacks
Author : decrypt
Score : 94 points
Date : 2021-12-15 17:38 UTC (5 hours ago)
(HTM) web link (brave.com)
(TXT) w3m dump (brave.com)
| ljhsiung wrote:
| 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=', 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-p...
|
| [1]: https://bugs.chromium.org/p/chromium/issues/detail?id=843157
|
| [2]: https://xsleaks.dev/
| zaltekk wrote:
| Here's the paper: https://arxiv.org/pdf/2112.06324.pdf
| akavel wrote:
| 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 wrote:
| 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.
| namelessoracle wrote:
| 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)
| PeterHolzwarth wrote:
| It is not bad that you thought that.
|
| But it is bad that you then decided to add a post to that
| effect.
| fuzzer37 wrote:
| I was thinking it had to do with the Habbo Hotel pool raids,
| personally.
| mlinksva wrote:
| The linked https://privacytests.org/ looks like a really useful
| aggregation/rundown/testing of privacy protecting features across
| browsers.
| akersten wrote:
| 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 wrote:
| Or the same ad network.
| annoyingnoob wrote:
| 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.
| ThunderSizzle wrote:
| I'll take Brave over Mozilla or Google right now. Size matters.
| rglullis wrote:
| 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 wrote:
| > 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-
| 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.
| rglullis wrote:
| Ok, if you want to be pedantic about it: it does not report
| any _user_ , private data. Better now?
|
| And read again, the page states clear that Brave does not
| learn anything about the user.
|
| The confirmation system is mostly to avoid client fraud.
| Not having such a system is against the interest of the
| users (they would lose reward-generating impressions to
| fraudsters) _and_ to publishers (who currently pay Google
| /Facebook/Twitter whatever they claim to have printed).
|
| Yes, it is an ad network. But as I said before, the problem
| is not with ads, it's the tracking and the industry
| practices. [0] we should be rooting for them to disrupt the
| industry, not just shrugging it off and hoping that the
| incumbents suddenly have a change of heart.
|
| [0] : https://news.ycombinator.com/item?id=29457492
| encryptluks2 wrote:
| I don't want a web browser reporting any data or
| telemetry about me period.
| rglullis wrote:
| It's opt-in. And the data is _not about you_!
|
| What is so difficult to understand?
| encryptluks2 wrote:
| It is opt out (telemetry data) but supposedly anonymized,
| so the data is about the user but is supposed to not be
| used in identifying them.
| rglullis wrote:
| No. We are talking about the ads system. That is
| completely opt-in.
|
| You are talking about their 3PA (Privacy-preserving
| Product Analytics) telemetry system, which has nothing to
| do with the ads.
| annoyingnoob wrote:
| Targeted advertising is by definition about _you_.
| Aggregated information that reports on targeted ads is
| about _you and others like you_.
|
| Personally, I'm willing to pay for a Browser that does
| not also need an ad network to support it.
|
| To quote Brave "The goal is to show you privacy
| respecting ads that are relevant to the user in the right
| context. This is done by "matching" an ad that is
| (ideally) catered to you based on your browsing
| activity". https://support.brave.com/hc/en-
| us/articles/360055013431-Why...
|
| It is clearly about _you_.
| pineconewarrior wrote:
| So is Chrome. This doesn't diminish the value of security
| research and subsequent improvements by either.
|
| I'll stick to Firefox anyway :)
| encryptluks2 wrote:
| Note that Firefox reports quite a lot of information by
| default and just like Chromium, you should look into using
| policies to prevent that.
| nojs wrote:
| 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 wrote:
| 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 wrote:
| 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.)
___________________________________________________________________
(page generated 2021-12-15 23:00 UTC)