|
cannam@48
|
1 Problem
|
|
cannam@48
|
2 =======
|
|
cannam@48
|
3
|
|
cannam@48
|
4 CPU usage amplification attack, similar to previous vulnerability
|
|
cannam@48
|
5 [2015-03-02-2][1].
|
|
cannam@48
|
6
|
|
cannam@48
|
7 Discovered by
|
|
cannam@48
|
8 =============
|
|
cannam@48
|
9
|
|
cannam@48
|
10 David Renshaw <david@sandstorm.io>
|
|
cannam@48
|
11
|
|
cannam@48
|
12 Announced
|
|
cannam@48
|
13 =========
|
|
cannam@48
|
14
|
|
cannam@48
|
15 2015-03-05
|
|
cannam@48
|
16
|
|
cannam@48
|
17 CVE
|
|
cannam@48
|
18 ===
|
|
cannam@48
|
19
|
|
cannam@48
|
20 CVE-2015-2313
|
|
cannam@48
|
21
|
|
cannam@48
|
22 Impact
|
|
cannam@48
|
23 ======
|
|
cannam@48
|
24
|
|
cannam@48
|
25 - Remotely cause a peer to execute a tight `for` loop counting from 0 to
|
|
cannam@48
|
26 2^29, possibly repeatedly, by sending it a small message. This could enable
|
|
cannam@48
|
27 a DoS attack by consuming CPU resources.
|
|
cannam@48
|
28
|
|
cannam@48
|
29 Fixed in
|
|
cannam@48
|
30 ========
|
|
cannam@48
|
31
|
|
cannam@48
|
32 - git commit [80149744bdafa3ad4eedc83f8ab675e27baee868][0]
|
|
cannam@48
|
33 - release 0.5.1.2:
|
|
cannam@48
|
34 - Unix: https://capnproto.org/capnproto-c++-0.5.1.2.tar.gz
|
|
cannam@48
|
35 - Windows: https://capnproto.org/capnproto-c++-win32-0.5.1.2.zip
|
|
cannam@48
|
36 - release 0.4.1.1:
|
|
cannam@48
|
37 - Unix: https://capnproto.org/capnproto-c++-0.4.1.2.tar.gz
|
|
cannam@48
|
38 - release 0.6 (future)
|
|
cannam@48
|
39
|
|
cannam@48
|
40 [0]: https://github.com/sandstorm-io/capnproto/commit/80149744bdafa3ad4eedc83f8ab675e27baee868
|
|
cannam@48
|
41
|
|
cannam@48
|
42 Details
|
|
cannam@48
|
43 =======
|
|
cannam@48
|
44
|
|
cannam@48
|
45 Advisory [2015-03-02-2][1] described a bug allowing a remote attacker to
|
|
cannam@48
|
46 consume excessive CPU time or other resources using a specially-crafted message.
|
|
cannam@48
|
47 The present advisory is simply another case of the same bug which was initially
|
|
cannam@48
|
48 missed.
|
|
cannam@48
|
49
|
|
cannam@48
|
50 The new case occurs only if the application invokes the `totalSize()` method
|
|
cannam@48
|
51 on an object reader.
|
|
cannam@48
|
52
|
|
cannam@48
|
53 The new case is somewhat less severe, in that it only spins in a tight `for`
|
|
cannam@48
|
54 loop that doesn't call any application code. Only CPU time is possibly
|
|
cannam@48
|
55 consumed, not RAM or other resources. However, it is still possible to create
|
|
cannam@48
|
56 significant delays for the receiver with a specially-crafted message.
|
|
cannam@48
|
57
|
|
cannam@48
|
58 [1]: https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2015-03-02-2-all-cpu-amplification.md
|
|
cannam@48
|
59
|
|
cannam@48
|
60 Preventative measures
|
|
cannam@48
|
61 =====================
|
|
cannam@48
|
62
|
|
cannam@48
|
63 Our fuzz test actually covered this case, but we didn't notice the problem
|
|
cannam@48
|
64 because the loop actually completes in less than a second. We've added a new
|
|
cannam@48
|
65 test case which is more demanding, and will make sure that when we do extended
|
|
cannam@48
|
66 testing with American Fuzzy Lop, we treat unexpectedly long run times as
|
|
cannam@48
|
67 failures.
|
