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