|
cannam@48
|
1 Problem
|
|
cannam@48
|
2 =======
|
|
cannam@48
|
3
|
|
cannam@48
|
4 CPU usage amplification attack.
|
|
cannam@48
|
5
|
|
cannam@48
|
6 Discovered by
|
|
cannam@48
|
7 =============
|
|
cannam@48
|
8
|
|
cannam@48
|
9 Ben Laurie <ben@links.org> using [American Fuzzy Lop](http://lcamtuf.coredump.cx/afl/)
|
|
cannam@48
|
10
|
|
cannam@48
|
11 Announced
|
|
cannam@48
|
12 =========
|
|
cannam@48
|
13
|
|
cannam@48
|
14 2015-03-02
|
|
cannam@48
|
15
|
|
cannam@48
|
16 CVE
|
|
cannam@48
|
17 ===
|
|
cannam@48
|
18
|
|
cannam@48
|
19 CVE-2015-2312
|
|
cannam@48
|
20
|
|
cannam@48
|
21 Impact
|
|
cannam@48
|
22 ======
|
|
cannam@48
|
23
|
|
cannam@48
|
24 - Remotely cause a peer to use excessive CPU time and other resources to
|
|
cannam@48
|
25 process a very small message, possibly enabling a DoS attack.
|
|
cannam@48
|
26
|
|
cannam@48
|
27 Fixed in
|
|
cannam@48
|
28 ========
|
|
cannam@48
|
29
|
|
cannam@48
|
30 - git commit [104870608fde3c698483fdef6b97f093fc15685d][0]
|
|
cannam@48
|
31 - release 0.5.1.1:
|
|
cannam@48
|
32 - Unix: https://capnproto.org/capnproto-c++-0.5.1.1.tar.gz
|
|
cannam@48
|
33 - Windows: https://capnproto.org/capnproto-c++-win32-0.5.1.1.zip
|
|
cannam@48
|
34 - release 0.4.1.1:
|
|
cannam@48
|
35 - Unix: https://capnproto.org/capnproto-c++-0.4.1.1.tar.gz
|
|
cannam@48
|
36 - release 0.6 (future)
|
|
cannam@48
|
37
|
|
cannam@48
|
38 [0]: https://github.com/sandstorm-io/capnproto/commit/104870608fde3c698483fdef6b97f093fc15685d
|
|
cannam@48
|
39
|
|
cannam@48
|
40 Details
|
|
cannam@48
|
41 =======
|
|
cannam@48
|
42
|
|
cannam@48
|
43 The Cap'n Proto list pointer format allows encoding a list whose elements are
|
|
cannam@48
|
44 claimed each to have a size of zero. Such a list could claim to have up to
|
|
cannam@48
|
45 2^29-1 elements while only taking 8 or 16 bytes on the wire. The receiving
|
|
cannam@48
|
46 application may expect, say, a list of structs. A zero-size struct is a
|
|
cannam@48
|
47 perfectly legal (and, in fact, canonical) encoding for a struct whose fields
|
|
cannam@48
|
48 are all set to their default values. Therefore, the application may notice
|
|
cannam@48
|
49 nothing wrong and proceed to iterate through and handle each element in the
|
|
cannam@48
|
50 list, potentially taking a lot of time and resources to do so.
|
|
cannam@48
|
51
|
|
cannam@48
|
52 Note that this kind of vulnerability is very common in other systems. Any
|
|
cannam@48
|
53 system which accepts compressed input can allow an attacker to deliver an
|
|
cannam@48
|
54 arbitrarily large uncompressed message using very little compressed bandwidth.
|
|
cannam@48
|
55 Applications should do their own validation to ensure that lists and blobs
|
|
cannam@48
|
56 inside a message have reasonable size. However, Cap'n Proto takes the
|
|
cannam@48
|
57 philosophy that any security mistake that is likely to be common in
|
|
cannam@48
|
58 naively-written application code is in fact a bug in Cap'n Proto -- we should
|
|
cannam@48
|
59 provide defenses so that the application developer doesn't have to.
|
|
cannam@48
|
60
|
|
cannam@48
|
61 To fix the problem, this change institutes the policy that, for the purpose of
|
|
cannam@48
|
62 the "message traversal limit", a list of zero-sized elements will be counted as
|
|
cannam@48
|
63 if each element were instead one word wide. The message traversal limit is an
|
|
cannam@48
|
64 existing anti-amplification measure implemented by Cap'n Proto; see:
|
|
cannam@48
|
65
|
|
cannam@48
|
66 https://capnproto.org/encoding.html#amplification-attack
|
|
cannam@48
|
67
|
|
cannam@48
|
68 Preventative measures
|
|
cannam@48
|
69 =====================
|
|
cannam@48
|
70
|
|
cannam@48
|
71 This problem was discovered through fuzz testing using American Fuzzy Lop,
|
|
cannam@48
|
72 which identified the problem as a "hang", although in fact the test case just
|
|
cannam@48
|
73 took a very long time to complete. We are incorporating testing with AFL into
|
|
cannam@48
|
74 our release process going forward.
|
