Denial of Service via Algorithmic Complexity Attacks

1
Denial of Service via Algorithmic Complexity
Attacks

• Scott A. Crosby and Dan S. Wallach
• Rice University

2
The attack

• Is a denial of service
• Worst case versus typical case
• Exploits the algorithm choices
• Algorithms are now part of the attack surface

3
Average vs. worst case behavior

• Hash tables O(1) vs. O(n)
• Binary trees O(log n) vs. O(n)
• Quicksort O(n log n) vs. O(n2)
• Regexp matchers O(n) vs. O(2n)
• Can an attacker induce interesting worst-case
  behavior on real software?
• This talk primarily about hash tables

4
The hash table under attack
Invulnerable or not under attack
Vulnerable and under attack
Total Cost 11
Total Cost 28
Assume scan whole chain before inserting into it
5
Requirements of attack

• Sufficient input to the program
• Search space of possible inputs is large enough
• Deterministic function
• Ability to get input to table

6
Insufficient input limiting impact

• Explicit application limits
• Implicit
• Max sockets
• Max processes
• System RAM
• O(n2), but microscopic constant factor
• Need thousands of collisions

7
Hash collision
8
Bucket collision
9
Which attack to use?

• Limited search space may make hash collisions
  impractical (e.g., 32 bit IP addr hash values)
• Hash collision
• Work regardless of bucket count
• May be harder to generate
• Bucket
• Easier to derive collisions
• Attack dependent on bucket count
• Multiple possible bucket counts
• Attack less efficient

10
Finding collisions

• Break the hash
• XOR
• Guess and check
• Cryptographic hash functions
• Exploit structure in the hash
• Fast attack on incremental hash functions
• Only need to do once offline, then reuse

11
Guess and check

• Hardest to collide is cryptographically secure
  hash functions
• E.g. MD5, SHA-1
• Still deterministic
• Not a magic bullet
• Nobody will use all 128/160 bits.
• Use guess-and-check to find bucket collisions
• 9,000 20-bit MD5 collisions in 1 hour
• P2-450

12
Exploit structure

• Incremental hash functions
• 32 bit internal state
• Input mixed one word at a time
• e.g. Perl 5.8.0, Perl 5.6.1, Java 1.4.1, Glib,
  Linux dcache, Python, TCL
• For Perl 90,000 in 1 hour, millions overnight

13
Fast collision

• If hash one byte at a time

• Find fixed points about 40 an hour

14
Fast collision

• Iterate fixed points

X
Y
abc
f
f
ff
0
h(XYabc) h(abc)
X
Z
abc
f
f
ff
0
h(XZabc) h(abc)
15
Now for the results

• Applications examined
• Perl 5.6.1
• Perl 5.8.0
• Dan Bernsteins DNS cache (djbdns) 1.05
• Squid 2.5STABLE1
• Bro IDS 0.8a2

16
Attacking perl

• Three order of magnitude difference in
  performance in inserting 90,000 keys

7200 seconds 2 hours
17
Attacking CGI scripts

• Recent results remote CGI DoS
• Scripting languages and other CGI systems
• Verified for Perl and Python
• Insert keys of POST request into hash table
• 10000 key test attack
• 250KB of data
• Saturate CPU for 3 minutes

18
Other applications

• djbdns DNS cache
• Has explicit check for chain gt100 long
• Bail out of chain scan if so and return miss
• Application specific compromise
• Squid HTTP proxy cache
• Uses MD5
• 40 more CPU consumption

19
Attacking an IDS

• IDS Intrusion Detection System
• Designed to identify scans and network intruders
• Attractive target
• Likely to have large state
• To better track connections and slow scans
• Unlikely to have other exposed vulnerabilities

20
Attacking Bro

• Bro intrusion detection system Paxson 98
• High performance, scriptable, open-source IDS
• Used by U.C. Berkeley/LBL to study their network
• Hash function cumulative XOR
• Demo port scanning detector
• Attack 16 kbit/second
• 50 SYN packets/second
• Carefully chosen source IP and dest port number
• We only cause at most 64k hash collisions

21
Bro performance under attack

• 16kbit/second attack
• Slam CPU in 7 minutes
• 60 seconds processing latency
• 31 drop rate

22
Results Summary
23
Wouldnt it be nice?
24
Wouldnt it be nice?
25
Wouldnt it be nice?
26
A fix old, but unfollowed

• Universal hashing
• Has deep theory provable results
• Original paper Carter, Wegman 79
• Also mentioned Cormen, Leiserson, Rivest 90
• Popular widespread algorithms textbook
• Warns about attacks against unkeyed hash
  functions
• Carter Wegmans implementation
• Dot product input with fixed random vector
• About as fast as Perls hash function (on
  Pentium2-450)

27
Another fix UMAC

• Fast, universal hash function
• Black, Halevi, Krawczyk, Krovetz, Rogoway 99
• Can be very fast
• UMAC (internet draft) hash function is
  asymptotically 80 the speed of Perls hash
  function
• Significantly faster than HMAC-MD5
• Much slower than Perl for short 10 byte inputs

28
Another fix HMAC-MD5

• Defined in RFC 2104
• Construction of keyed hash function
• from a cryptographic hash function
• Security not provable without assumptions
• Very slow
• Half the speed of UMAC for long strings
• Twentieth the speed of Perl for short strings

29
Possible fix the Jenkins hash

• Popular, fast, keyed hash function
• http//burtleburtle.net/bob/hash/evahash.html
• Built primarily for speed, good distribution
• Two different functions
• No multiplies or modulo
• These are fast on x86, slow on SPARC
• Used for performance reasons
• No serious cryptanalysis
• No obvious weaknesses, either

30
Since this paper was published

• Systems got fixed
• Linux
• Network routing cache vulnerable and fixed
• Directory-entry cache vulnerable and fixed
• EXT2 filesystem predicted the attack, safe
• Bro
• Fixed
• Perl 5.8.1 (not yet released)
• Fix exposes latent bugs

31
Related work

• QuickSort worst case input McIlroy 99
• Perl hash worst case runtime Dominus 97
• Attacking port scanning detectors Solar
  Designer 98
• Defensive programming Qie, Pang, Peterson 02
• Using client puzzles Dean, Stubblefield 01

32
Is hash randomization enough?

• Collisions introduce latency
• Latency can be measured on real networksBoneh,
  Brunley 03
• Can an opponent determine collisions?
• Possibly determine the hash functions key

33
Conclusion

• Attackers will go after your worst-case
  performance
• Better hash functions available, not widely used
• Where else are there vulnerable data structures?
• Routers?
• P2P / DHT systems?
• http//www.cs.rice.edu/scrosby/hash/

34
Advertisement for my WiP talk

• Regular expression matchers
• Use backtracking
• Try one alternative, then the other
• Can match irregular languages
• Can take exponential time!
• (aaa)Y
• aaaaaaaaaaaaaaaaaaaaaaaaX

35
Questions

• ?

?
?
36
Bro performance under attack

• 16kbit/second attack
• Slam CPU in 7 minutes
• 50 seconds processing latency
• 31 drop rate

37
Our fix wcHASH

• CW needs storage for random vector
• 4 times length of longest input to hash
• UMAC is slow for short keys
• Our approach hybrid
• Use CW dot-product for small inputs
• Use UMAC for large inputs
• Worst case 50 of Perls hash performance

38
Finding collisions Trivial

• Simple hash functions reverse engineer
• e.g. XOR

39
Keying hash functions is hard

• BUZHash
• Any 64 byte input concatenated with itself
  collides.
• All multiplicative hashes
• Keying initial state doesnt affect collision
• Future work needed
• Current hash functions too slow
• Fast hash functions not known to be secure