Exposure of HashMap iteration order allows for O(n²) blowup.

[Veedrac]

Exposing HashMap's iteration order can cause O(n²) blowup even in innocent-looking code without the presence of an attacker. In the presence of an attacker, access to the order of a dictionary allows HashDoS-like attacks with only two requests in common scenarios.

Without an attacker

Consider a user with two possibly-disjoint hash maps

let first_map: HashMap<u64, _> = (0..900000).map(|i| (i, ())).collect();
let second_map: HashMap<u64, _> = (900000..1800000).map(|i| (i, ())).collect();

The user wants to merge the hash maps, and does so naïvely,

let mut merged = first_map;
merged.extend(second_map);

Time for merge when second_map is shuffled: 0.4s

Time for merge when second_map is not shuffled: 40.s (x100 amplification)

This effect is noticeably more pronounced when merging with a round robin strategy.

With an attacker

The threat model here is simple. The attacker is able to send JSON to the server. The server parses the JSON into a HashMap and through whatever means - an error message including the formatted map or explicit listing of the contents of the map - may reveal the order of the map.

The attack on this model requires two requests. The first sends some large JSON to the server

let first_request: HashMap<u64, _> = (0..900000).map(|i| (i, ())).collect();

and recieves an ordering

let returned_data: Vec<_> = first_request.into_iter().collect();

The attacker then sends the first and third quarter of this list in a new JSON object.

let second_request: HashMap<u64, _> =
 returned_data[..225000].iter()
     .chain(&returned_data[450000..675000])
     .cloned().collect();

Total time without second request: 0.1s

Total time with second request: 200s (x2000 amplification)

---

Solutions, near-solutions and non-solutions

These solutions should not be considered to be ordered, necessarily disjoint, nor an exhaustive list of options.

Fall back to BTreeMap

It should be clear that we cannot treat hash maps as a solved problem just because we use SipHash. In fact, SipHash is entirely insufficient to solve the problem. My first suggestion is thus to stop trying to make the hasher secure, and instead fall back to BTreeMap when nonlinear behaviour is detected.

This guarantees a minimum level of performance regardless of the capabilities of the attacker, and allows usage of a faster hashing algorithm by default. Hash maps should get faster by default as a result. This does not prevent having to consider the issue, since the fallback is costly and must be rare, but this is an easier problem than entirely securing the hash map.

Use a hash map without problematic blowup, or less affected by it

Java solves this problem by using a hash map with chaining and converting large buckets to tree maps. This mitigates the impact of degradation, but does not seem to allow using contiguous hash maps by default.

As far as I am aware, the blowup cannot be resolved by moving to another common form of open addressing, although quadratic probing would be significantly less affected by some of these attacks. Chaining alone also defeats the attacks given here, but still requires a secure hash and fails with attackers with more capabilities.

Use different seeds for each hash map

Pull requests #31356 (closed) and #33318 (merged) first proposed incrementing the thread local seed for each hash map. This was later removed when no threat model was seen, but would prevent both attacks listed here.

This still allows attacks when hash maps are reused.

Randomize iteration order

I am not sure how one would randomize iteration order efficiently. However, it should solve the problem unless hashes are exposed through other means.

Ignore the problem

Given that Rust went so far as to use SipHash, quadratic blowup on code as simple as fst.extend(snd) seems too extreme to ignore.

[sfackler]

It seems to me like we should basically just revert #33318 for now and use different seeds per map. Ideally we could find a strategy that avoids key reuse but also doesn't regress hashmap creation performance too much, but as @briansmith noted in #33318 there are risks to using multiple correlated keys as well.

[sfackler]

cc @rust-lang/libs

[briansmith]

The threat model here is simple. The attacker is able to send JSON to the server. The server parses the JSON into a HashMap and through whatever means - an error message including the formatted map or explicit listing of the contents of the map - may reveal the order of the map.

Perhpas we can resolve this by just saying this is outside the threat model. And/or, the Debug implementation for a HashMap isn't performance-sensitive in most applications, and so it could be redone to always output the values in sorted order by key--i.e. it could make a copy of itself into a BTreeMap and then Debug::fmt the BTreeMap. This seems reasonable since either the HashMap is small or it is probably too gigantic to reasonably expect to format in the first place. (Note that HashMap doesn't implement Display, not should it.)

[sfackler]

We'd also have to mandate a sort in JSON serialization, which seems somewhat unreasonable.

The fact that simply merging two maps can run into sadness makes it seem to me like we have to do something about this.

[Veedrac]

You can't always sort a hashmap because the keys aren't required to be Ord. This doesn't matter for the BTreeMap fallback because you can sort by hash code (note: this means it's required to use a cryptographic hash), but sorting by hash is exactly the opposite of what you want to do when you don't have that fallback.

[sfackler]

A shuffle would do fine though I think.

[eternaleye]

@briansmith: Debug is just a trivial example of how the information might leak, though, not the actual issue.

Another example would be if a web service validates the JSON it's given key-by-key, by iterating over (key, value) pairs and delegating to a validation function.

• If it returns the first error it encounters, the attacker can learn the order.
• If it errors early, even without a descriptive message, the attacker can learn the order.
• If it collects the errors and returns them without shuffling (or sorting), the attacker can learn the order.

It's a footgun.

[Veedrac]

We could also use Python's technique to preserve insertion order. It introduces a little more indirection, but the cost doesn't seem to be excessive.

This also makes hash map order deterministic, which is a nice usability bonus. Note that tombstones aren't required for determinism, but are required to preserve insertion order through deletions. Either way prevents the attacks given.

[arthurprs]

Revisiting #33318 sounds like the reasonable way out.

[arielb1]

HashMap creation needs to be fast in the common case. I think we need a HashMap that defaults to FNV but rehashes with a random SIP key when it gets too much collisions.

[eternaleye]

TBH, I'm also curious how alternate approaches (a BTreeMap whose nodes are stored in an overallocated Vec, for similar allocation amortization as HashMap; a trie or crit-bit tree keyed on hashes with the same allocation style, etc) would perform.

Both would likely avoid the pathological merging behavior, and the amortized allocations may bring them closer to HashMap.

[arielb1]

So the problem here is not hard collisions, but rather soft collisions?

[bluss]

@Veedrac It has some wins too, since the data that needs to be swapped by bucket stealing while inserting is smaller, and iteration is much faster since it's on a mostly compact space. But the indirection costs in lookup may not be acceptable at all. (I made a prototype that demonstrates exactly these differences with a +6% hit to lookup.)

Maybe if one moves the hash field to be next to the index, or even special case smaller than 2**32 maps so that they keep 32-bit hashes and 32-bit indices next to each other?

[Veedrac]

@bluss The new layout should allow you to lower the occupancy (perhaps cap it at 80%?) without paying much of a hit, since the key/value arrays can safely cap out at 100% - only the index array needs to grow. This should get you some speed back, as well as make pathological insertions a lot rarer.

[Veedrac]

@arielb1 Exactly; the first half of the table is ending up with significantly over 100% occupancy.

[Veedrac]

Some extra discussion is available in this Reddit thread, including back of the envelope analysis of the asymptotics and commentary on a similar attack mentioned in the SipHash paper.

[bluss]

the consistent order map prototype is here https://github.com/bluss/ordermap I actually began that not because of this thread but due to curiosity about the new dict representation in Python 3.6.

Removal breaks the insert order property. Otherwise you need tombstones (ideas/forks for efficient way of doing that are welcome).

Conclusions: iteration can be so much faster than libstd HashMap. Growth too. Lookup is slightly slower (more than the 6% I said above if the map is large and out of cache). It solves the merge pathology.

[sfackler]

That looks pretty awesome at first glance.

I don't think like we need to guarantee insertion order iteration, but it would be nice to make it iterate more obviously in not-insertion order - maybe alternate adding to the front and back of the iteration list or something like that? Probably not worth doing if it'd get complex.

[bluss]

However it looks in this issue, the current HashMap impl has lots of aspects in which its performance is great already. Don't think it's that easy to replace it.

[sfackler]

Oh yeah, absolutely. It's just good to see that there are reasonable routes forward.

[Veedrac]

@bluss Safe, stable Rust and only 6% slower insertion normally? Amazing work.

[bluss]

The particular representation in ordermap maps well to safe rust (using vectors without holes). Making accurate benchmarks is tricky (there are so many different scenarios), I can only ask for help there, and my general summary is in the readme.

[alexcrichton]

The libs team discussed this during triage yesterday and the conclusion was that while we'd definitely like to fix this it's not absolutely critical we do so immediately. We don't mind taking a bit of time to explore our options like @bluss's crate.

[arthurprs]

I don't think the situation can be improved further without a substantial trade-off (all changes so far had essentially no cost in neither memory nor runtime) but I'm curious what other people think.

[Veedrac]

OrderMap hides iteration order and seems to be faster in most scenarios than std's HashMap according to other people. It's not totally without drawbacks, but it seems worth consideration.

[arthurprs]

Then you get into the substantial trade-off part, it's faster for iterations/inserts/deletes but you pay consuming more memory and slower lookup.

[Veedrac]

The Github page says

Lookup is faster than libstd HashMap for "small" tables (below something like 100 000 key-value pairs), but suffers under load more due to the index vec to entries vec indirection still.

Memory should be less for large elements, too, so it's not clear-cut there either.

[arthurprs]

That's not true anymore, I think I removed most of the overhead of the std hashmap bucket interface. In the current state of things it's not uncommon to have order-map consuming (see comment bellow) the memory.

_unif can lookup any key from the key set and the non _unif accesses only 10% of the key set (zipf like).

test ord_::lookup_100_000             ... bench:     356,040 ns/iter (+/- 25,036)
test ord_::lookup_100_000_unif        ... bench:     363,378 ns/iter (+/- 480,153)
test ord_::lookup_1_000_000           ... bench:  13,376,270 ns/iter (+/- 1,429,406)
test ord_::lookup_1_000_000_unif      ... bench:  13,502,113 ns/iter (+/- 1,349,924)
test std_::lookup_100_000             ... bench:     344,022 ns/iter (+/- 20,305)
test std_::lookup_100_000_unif        ... bench:     346,890 ns/iter (+/- 150,954)
test std_::lookup_1_000_000           ... bench:   8,534,857 ns/iter (+/- 592,409)
test std_::lookup_1_000_000_unif      ... bench:   8,731,387 ns/iter (+/- 893,121)

[arthurprs]

--- edit: math is hard

Ok 2x memory is totally off, I think it's more like
y = ( 8 / (0.75 * 0.75) + (8 + x) / (1.0 * 0.75) ) / ( (8 + x) / (0.91 * 0.75) )

Which is ~11% for a (K, V) of 40 bytes.

[arthurprs]

While I was at it and for the sake of completeness

std -> ordermap

➜  hashmap2 git:(adapt) ✗ cargo benchcmp std_ ord_ bench.txt
 name                          std_ ns/iter  ord_ ns/iter  diff ns/iter   diff % 
 ::grow_100_000                8,950,163     6,774,414       -2,175,749  -24.31% 
 ::grow_10_000                 731,130       475,714           -255,416  -34.93% 
 ::grow_big_value_10_000       1,644,737     962,251           -682,486  -41.50% 
 ::insert_100_000              4,358,280     4,104,093         -254,187   -5.83% 
 ::insert_10_000               269,920       283,011             13,091    4.85% 
 ::insert_int_bigvalue_10_000  701,788       581,711           -120,077  -17.11% 
 ::insert_str_10_000           274,906       288,666             13,760    5.01% 
 ::insert_string_10_000        746,560       683,109            -63,451   -8.50% 
 ::iterate_100_000             386,084       67,899            -318,185  -82.41% 
 ::lookup_100_000              368,827       376,037              7,210    1.95% 
 ::lookup_100_000_unif         445,130       521,884             76,754   17.24% 
 ::lookup_1_000_000            8,457,146     12,819,619       4,362,473   51.58% 
 ::lookup_1_000_000_unif       8,761,012     13,058,826       4,297,814   49.06% 

86% load factor std lib -> ordmap

➜  hashmap2 git:(adapt) ✗ cargo benchcmp s86_ ord_ bench.txt
 name                          s86_ ns/iter  ord_ ns/iter  diff ns/iter   diff % 
 ::grow_100_000                7,975,130     6,774,414       -1,200,716  -15.06% 
 ::grow_10_000                 597,496       475,714           -121,782  -20.38% 
 ::grow_big_value_10_000       1,453,406     962,251           -491,155  -33.79% 
 ::insert_100_000              4,420,082     4,104,093         -315,989   -7.15% 
 ::insert_10_000               273,364       283,011              9,647    3.53% 
 ::insert_int_bigvalue_10_000  702,656       581,711           -120,945  -17.21% 
 ::insert_str_10_000           279,262       288,666              9,404    3.37% 
 ::insert_string_10_000        735,912       683,109            -52,803   -7.18% 
 ::iterate_100_000             394,462       67,899            -326,563  -82.79% 
 ::lookup_100_000              366,745       376,037              9,292    2.53% 
 ::lookup_100_000_unif         434,933       521,884             86,951   19.99% 
 ::lookup_1_000_000            8,465,497     12,819,619       4,354,122   51.43% 
 ::lookup_1_000_000_unif       8,668,845     13,058,826       4,389,981   50.64% 

stdlib -> 86% load factor std lib

➜  hashmap2 git:(adapt) ✗ cargo benchcmp std_ s86_ bench.txt
 name                          std_ ns/iter  s86_ ns/iter  diff ns/iter   diff % 
 ::grow_100_000                8,950,163     7,975,130         -975,033  -10.89% 
 ::grow_10_000                 731,130       597,496           -133,634  -18.28% 
 ::grow_big_value_10_000       1,644,737     1,453,406         -191,331  -11.63% 
 ::insert_100_000              4,358,280     4,420,082           61,802    1.42% 
 ::insert_10_000               269,920       273,364              3,444    1.28% 
 ::insert_int_bigvalue_10_000  701,788       702,656                868    0.12% 
 ::insert_str_10_000           274,906       279,262              4,356    1.58% 
 ::insert_string_10_000        746,560       735,912            -10,648   -1.43% 
 ::iterate_100_000             386,084       394,462              8,378    2.17% 
 ::lookup_100_000              368,827       366,745             -2,082   -0.56% 
 ::lookup_100_000_unif         445,130       434,933            -10,197   -2.29% 
 ::lookup_1_000_000            8,457,146     8,465,497            8,351    0.10% 
 ::lookup_1_000_000_unif       8,761,012     8,668,845          -92,167   -1.05% 

code: https://github.com/arthurprs/hashmap2/blob/adapt/benches/bench.rs

[bluss]

Can you spell out the memory calculations more explicitly?

[arthurprs]

I'm not sure I got that 100% right but here it goes:

Assume you're calculating the average case (between resizes, relative load factor is 1 when full and 0.5 after resize). For that multiply the actual factors by Z = (1+0.5)/2 = 0.75.

Ordmap = (size of index / (indexes_load * Z)) + (size of pair+size of hash) / (pairs_load * Z) = 8 / (0.75 * 0.75) + (8 + x) / (1.0 * 0.75)
Std = (size of hash+ size of pair) / (load factor * Z) = (8 + x) / (0.91 * 0.75)

[bluss]

Thanks

[stjepang]

Any progress on this? Do we have a plan for fixing the DoS unsafety?

[arthurprs]

There's a bit of history in this thread, so I'll try to summarize the current state bellow.

#38368 improved things immensely by detecting degenerate probe lengths and/or forward shifting on insert. There's also a check for minimum occupancy in order to trigger the early resize (so a runtime attack don't become a memory attack). This is somewhat similar to Java's solution. They convert the linked-list collision chain into a balanced-tree when the length crosses a threshold.

So there's still a small area that an attacker can exploit, by crafting inputs that cause extra work below those limits. That's really small though and I didn't test if one can actually exploit it.

Edit: Also, default hasher gives each hashmap a different seed (clone() retains the seed though), but that's orthogonal to the above.

[alkis]

Here's a general solution to the problem. after every rehash or clone, reseed the hasher. It will regress the performance of rehash but it will solve the O(n²) problem. Luckily in production code (as a whole) lookups dominate insertions by a large margin so the tradeoff is actually sound.

Note: if you end up going this route it might no longer make sense to store the full hashes in the hashtable as they are not going to help when rehashing (they are still going to save comparisons but it is likely that the costs outweigh the benefits). You can instead store the distance from the ideal position in a u8. This will reduce the amount of memory touched until finding the element or terminating the search.

[funny-falcon]

@alkis

it might no longer make sense to store the full hashes ...
they are still going to save comparisons

Storing of 8bits of hash is enough to save comparisons. Actually, I even stored 7bits with great result (using 8bit for other purpose).
If this "hashik" is always non-zero (ie calculated as hshik = hash % 251 + 1), then it could role of "presence" flag.
(Module by a constant is optimized by compiler into two multiplications).

[arthurprs]

That's not general as it requires support from the hasher, most just initialize to the same seed. Edit: can be made general by hashing the table address as well #36481 (comment)

I don't think that's a reasonable tradeoff for a stdlib hasher, growing and cloning the hashmap becomes much much slower. As the slot moving is essentially randomized it'll require a lot of random access and Robin hood adjustments as things go into the new table. The fact that sip isn't the fastest hasher around just makes it even worse.

[alkis]

@funny-falcon if we store 8-bits of hash for comparisons then we can't bail out early from probe chains based on distance from ideal position. It basically voids the Robin Hood. Or perhaps I misunderstood your suggestion.

@arthurprs yes either BuildHasher or Hasher traits need an additional requirement. BuildHasher can support it by requiring Default and Hasher by allowing setting the seed. You are right there is going to be a performance hit - I already mentioned it "it regresses the performance of rehash". I posit there is no win-win solution here. You either take performance hit by shuffling the order on rehash or you have O(n²) on insertion. As already mentioned, in the global scheme of things this does not matter: insertions happen orders of magnitude less often than lookups. Also a lot of the regression can be mitigated by using reserve().

[funny-falcon]

@alkis , I mean, store both 8bits of hash + 8bits distance. So, 16 bits in total.
Storing just 16bits of hash is less meaningful, cause in big table they all will be equal for same position.
(that is another reason why "hashik" is modulo prime: for same table position there will be 251 different "hashik").

[alkis]

@funny-falcon This makes sense 👍

[arthurprs]

That's not reasonable, it's too easy to trip on that land-mine.

The most reasonable trade-off I've seen thus far is the two array map (OrderMap), that "fixes" the problem by making the degenerate case cheap to a point it can't really be exploited.

[alkis]

@arthurprs there is a way to "reseed" without requiring support from either BuildHasher or Hasher and placing no extra requirements to the user. Instead of hashing the key like this:

let mut state = hash_state.build_hasher();
t.hash(&mut state);
t.finish()

use the pointer to the buckets as additional bytes (this becomes a naturally occurring seed that changes at all the right places):

let mut state = hash_state.build_hasher();
state.write_usize(table.hash_start as usize);
t.hash(&mut state);
t.finish()

EDIT: The disadvantage to this solution is that if hash(usize) + hash(T) is slower than set_seed(seed) + hash(T) we get a suboptimal implementation. If there was an API in BuildHasher to create a Hasher with a specific seed then this could be done more efficiently across all hashers. This can be done by changing BuildHasher::build_hasher to take an additional argument. I am not sure how feasible this is at this point.

[arthurprs]

@alkis neat! That makes it general.

[alkis]

Any takers to implement this approach and close this bug once and forall? :-)

[arthurprs]

One has to provide proof that the performance hit isn't huge. I'd not be surprised if this fix yields a ~500% hit on grow/clone and a 20+% hit on lookup when using sip13.

[funny-falcon]

There is even no need to calculate new hash value each time.
(Sorry, I don't know rust well, so I'll try to copy from above)

// key hash calculated once and stored
let mut state = hash_state.build_hasher();
t.hash(&mut state);
hashvalue = SafeHash.new(state.finish());
// position calculated dependent on storage pointer
// (example for 64bit)
poshash = hashvalue + (table.hash_start as usize);
poshash ^= poshash >> 32
poshash *= 0xdeadcafe71febeef; // or some other "well known" odd number (from Murmur, CityHash, etc)
poshash ^= poshash >> 32;

It will be enough for fixing bad case, and there is no need in recalculating SipHash.

[alkis]

@funny-falcon I do not think this will be very good. The pointer to hash_start has low entropy and the difference between one hash_starrt and another can be very small. I think mixing this way will weaken the composite hashfunction. Let's see how it works without this optimization first and then decide if this tradeoff is worth it. Perhaps some hash function experts can weigh in as well.

[funny-falcon]

@alkis, just try. It will be just enough to fix bad case. There is no need to be better.

I think mixing this way will weaken the composite hashfunction

No way. hashvalue calculated with SipHash, and poshash is calculated in bijective way (ie it is revertible).

Multiplying by a "random looking" constant and shifting provides really good results. This is a well-known technique (Knuth multiplicative hashing).

Simulation (in C):

#include <stdio.h>
#include <stdlib.h>
#include <inttypes.h>

uint64_t poshash(uint64_t hv, uint64_t hs) {
	uint64_t ph;
	ph = hv + hs;
	ph ^= ph >> 32;
	ph *= 0xdeadcafe71febeeful;
	ph ^= ph >> 32;
	return ph;
}

int main(int ac, char** av) {
	int i, j;
	uint64_t hv1, hv2, hv3, hashstart;
	uint64_t ph1, ph2, ph3;
	uint64_t masks[3] = {0xffff, 0x7fff, 0x3fff};

	hv1 = 0x123456789abcdef0ul;
	hv2 = 0x98523aed81fcdef0ul;
	hv3 = 0x3fa83924dcbcdef0ul;
	hashstart = 0x00007fe342e50000ul;
	printf("\thv1\thv2\thv3\n");
	for (j=0; j<3; j++) {
		uint64_t mask = masks[j];
		printf("%lx\t%lx\t%lx\t%lx\n",
			mask, hv1 & mask, hv2 & mask, hv3 & mask);
	}
	for (i=0; i<5; i++) {
		uint64_t ph1, ph2, ph3;
		ph1 = poshash(hv1, hashstart);
		ph2 = poshash(hv2, hashstart);
		ph3 = poshash(hv3, hashstart);
		printf("\t----\t----\t----\n");
		for (j=0; j<3; j++) {
			uint64_t mask = masks[j];
			printf("%lx\t%04lx\t%04lx\t%04lx\n",
				mask, ph1 & mask, ph2 & mask, ph3 & mask);
		}
		hashstart += 0x100ul; /* next allocation */
	}
}

results:

mask	hv1	hv2	hv3
ffff	def0	def0	def0
7fff	5ef0	5ef0	5ef0
3fff	1ef0	1ef0	1ef0
-----	-------	-------	------
ffff	8b86	f7a3	ae2e
7fff	0b86	77a3	2e2e
3fff	0b86	37a3	2e2e
-----	-------	-------	------
ffff	fd87	41a6	202d
7fff	7d87	41a6	202d
3fff	3d87	01a6	202d
-----	-------	-------	------
ffff	6f85	d3a5	522c
7fff	6f85	53a5	522c
3fff	2f85	13a5	122c
-----	-------	-------	------
ffff	518c	1ddf	c42a
7fff	518c	1ddf	442a
3fff	118c	1ddf	042a
-----	-------	-------	------
ffff	c38d	afde	7629
7fff	438d	2fde	7629
3fff	038d	2fde	3629

[funny-falcon]

https://en.wikipedia.org/wiki/Universal_hashing#Constructions

It is possible to use more sofisticated "multiply-add-shift":

ph = hashvalue + (table.hash_start as usize);
ph ^= ph >> 32;
ph *= 0xacd5ad43274593b9;
ph += 0x6956ab76ed268a3d;
ph ^= ph >> 32;

But really there is no need for the usecase. Just "multiply-shift" is more than enough.

[steveklabnik]

Triage: #56241 (comment) and #56241 (comment)