2015-03-05-0-c++-addl-cpu-amplification.md 1.95 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Problem
=======

CPU usage amplification attack, similar to previous vulnerability
[2015-03-02-2][1].

Discovered by
=============

David Renshaw <david@sandstorm.io>

Announced
=========

2015-03-05

17 18 19 20 21
CVE
===

CVE-2015-2313

22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
Impact
======

- Remotely cause a peer to execute a tight `for` loop counting from 0 to
  2^29, possibly repeatedly, by sending it a small message. This could enable
  a DoS attack by consuming CPU resources.

Fixed in
========

- git commit [80149744bdafa3ad4eedc83f8ab675e27baee868][0]
- release 0.5.1.2:
  - Unix: https://capnproto.org/capnproto-c++-0.5.1.2.tar.gz
  - Windows: https://capnproto.org/capnproto-c++-win32-0.5.1.2.zip
- release 0.4.1.1:
  - Unix: https://capnproto.org/capnproto-c++-0.4.1.2.tar.gz
- release 0.6 (future)

[0]: https://github.com/sandstorm-io/capnproto/commit/80149744bdafa3ad4eedc83f8ab675e27baee868

Details
=======

Advisory [2015-03-02-2][1] described a bug allowing a remote attacker to
Jakub Wilk's avatar
Jakub Wilk committed
46
consume excessive CPU time or other resources using a specially-crafted message.
47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67
The present advisory is simply another case of the same bug which was initially
missed.

The new case occurs only if the application invokes the `totalSize()` method
on an object reader.

The new case is somewhat less severe, in that it only spins in a tight `for`
loop that doesn't call any application code. Only CPU time is possibly
consumed, not RAM or other resources. However, it is still possible to create
significant delays for the receiver with a specially-crafted message.

[1]: https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2015-03-02-2-all-cpu-amplification.md

Preventative measures
=====================

Our fuzz test actually covered this case, but we didn't notice the problem
because the loop actually completes in less than a second. We've added a new
test case which is more demanding, and will make sure that when we do extended
testing with American Fuzzy Lop, we treat unexpectedly long run times as
failures.