New attack?: 1. Insert N elems 2. Iterate; save iteration order 3. Remove all 2. Re-insert all in same HT in same order
-
-
Compare to this prior to "fix": 1. Insert N elems into a HT. 2. Force copy of those elems into a new HT. Both O(n**2)?
1 reply 0 retweets 0 likes -
Replying to @BRIAN_____ @ManishEarth
this doesn't work because we don't shrink; the "attack" is reliant on having a lower cap table.
1 reply 0 retweets 0 likes -
so basically you also need to get a shrink_to_fit in there.
2 replies 0 retweets 0 likes -
that's convoluted enough that I think it's reasonable to say "this isn't a significant concern in practice"
2 replies 0 retweets 0 likes -
Replying to @Gankro @ManishEarth
Perhaps. But I came up with these two in a few minutes during this chat. Almost definitely there are others.
1 reply 0 retweets 1 like -
This makes me think that the unique-key-per-HashMap is fragile and so likely not a security mechanism to be relied on.
1 reply 0 retweets 2 likes -
Replying to @BRIAN_____ @ManishEarth
this leaves only two solutions: tree fallback, or educate the world that hashmaps shouldn't *store* untrusted input
1 reply 0 retweets 0 likes -
I personally live in a fuzzier world, where it's ok to apply minor mitigations as long as the perf impact is low
2 replies 0 retweets 0 likes -
Replying to @Gankro @ManishEarth
If you could look at recent comments in the GitHub issues, you'd see suggestions about adding custom HMAC-SipHash, etc.
2 replies 0 retweets 0 likes
And this all makes me think that perhaps it's worth reconsidering the whole approach.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.