VULNERABILITY DETAILS
HashDOS attack despite randomization in v8 hash tables

VERSION
Chrome Version: [any] + [any]
Operating System: [any]

REPRODUCTION CASE
Not available.

Recently a so-called hashdos bug in nodejs, which gets its code from v8, got some public attention [1]. The nodejs bug was about the lack of randomizing the hash in hash tables.

However I believe even with randomization the hash tables are still vulnerable to hashdos attacks. Here's the code that calculates the hash:
https://cs.chromium.org/chromium/src/v8/src/string-hasher-inl.h?l=28

It's a relatively simple hash function operating with some shifts.

Some explanation about the history of hashdos attacks:
At the 28C3 (2007) Alexander Klink and Julian Wäldle revealed that many popular hashtable implementations are trivially vulnerable to hashdos-ing by creating inputs that all hash to the same value and thus make a hashtable implementation extremely inefficient. They recommended randomization as a countermeasure
However one year later at 29C3 Bernstein, Boßlet and Aumasson [3] showed that practically all "simple" hash functions that were in use for hash tables can still be attacked, as it's possible to create colliding inputs despite randomization. They presented practical attacks against many popular hashes like murmurhash.

Thus in order to properly fix hashdos-ing one needs two things:
a) randomization of the hash input
b) a secure hash function that prevents targeted collisions.

Many implementations were only half-fixed. They did a), but lack b).

The gold standard for b) is usually siphash. However other hashes are also possible if they provide the proper cryptographic properties. Go uses an aes-based hash on architectures that have aes acceleration [4].

The code for the string hash in v8 is here:
https://cs.chromium.org/chromium/src/v8/src/string-hasher-inl.h?l=28

I don't know what hash that is, it doesn't seem to match one of the popular ones (murmurhash, djb33x), but it also certainly doesn't look like a secure hash. I asked JP Aumasson, he commented "doesnt look familiar, but seems pretty weak".

I recommend replacing this algorithm with siphash.

[1] https://nodejs.org/en/blog/vulnerability/july-2017-security-releases/
[2] https://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html
[3] https://events.ccc.de/congress/2012/Fahrplan/events/5152.en.html
[4] https://github.com/golang/go/issues/4604