cannam@48: Problem
cannam@48: =======
cannam@48: 
cannam@48: CPU usage amplification attack.
cannam@48: 
cannam@48: Discovered by
cannam@48: =============
cannam@48: 
cannam@48: Ben Laurie <ben@links.org> using [American Fuzzy Lop](http://lcamtuf.coredump.cx/afl/)
cannam@48: 
cannam@48: Announced
cannam@48: =========
cannam@48: 
cannam@48: 2015-03-02
cannam@48: 
cannam@48: CVE
cannam@48: ===
cannam@48: 
cannam@48: CVE-2015-2312
cannam@48: 
cannam@48: Impact
cannam@48: ======
cannam@48: 
cannam@48: - Remotely cause a peer to use excessive CPU time and other resources to
cannam@48:   process a very small message, possibly enabling a DoS attack.
cannam@48: 
cannam@48: Fixed in
cannam@48: ========
cannam@48: 
cannam@48: - git commit [104870608fde3c698483fdef6b97f093fc15685d][0]
cannam@48: - release 0.5.1.1:
cannam@48:   - Unix: https://capnproto.org/capnproto-c++-0.5.1.1.tar.gz
cannam@48:   - Windows: https://capnproto.org/capnproto-c++-win32-0.5.1.1.zip
cannam@48: - release 0.4.1.1:
cannam@48:   - Unix: https://capnproto.org/capnproto-c++-0.4.1.1.tar.gz
cannam@48: - release 0.6 (future)
cannam@48: 
cannam@48: [0]: https://github.com/sandstorm-io/capnproto/commit/104870608fde3c698483fdef6b97f093fc15685d
cannam@48: 
cannam@48: Details
cannam@48: =======
cannam@48: 
cannam@48: The Cap'n Proto list pointer format allows encoding a list whose elements are
cannam@48: claimed each to have a size of zero. Such a list could claim to have up to
cannam@48: 2^29-1 elements while only taking 8 or 16 bytes on the wire. The receiving
cannam@48: application may expect, say, a list of structs. A zero-size struct is a
cannam@48: perfectly legal (and, in fact, canonical) encoding for a struct whose fields
cannam@48: are all set to their default values. Therefore, the application may notice
cannam@48: nothing wrong and proceed to iterate through and handle each element in the
cannam@48: list, potentially taking a lot of time and resources to do so.
cannam@48: 
cannam@48: Note that this kind of vulnerability is very common in other systems. Any
cannam@48: system which accepts compressed input can allow an attacker to deliver an
cannam@48: arbitrarily large uncompressed message using very little compressed bandwidth.
cannam@48: Applications should do their own validation to ensure that lists and blobs
cannam@48: inside a message have reasonable size. However, Cap'n Proto takes the
cannam@48: philosophy that any security mistake that is likely to be common in
cannam@48: naively-written application code is in fact a bug in Cap'n Proto -- we should
cannam@48: provide defenses so that the application developer doesn't have to.
cannam@48: 
cannam@48: To fix the problem, this change institutes the policy that, for the purpose of
cannam@48: the "message traversal limit", a list of zero-sized elements will be counted as
cannam@48: if each element were instead one word wide. The message traversal limit is an
cannam@48: existing anti-amplification measure implemented by Cap'n Proto; see:
cannam@48: 
cannam@48: https://capnproto.org/encoding.html#amplification-attack
cannam@48: 
cannam@48: Preventative measures
cannam@48: =====================
cannam@48: 
cannam@48: This problem was discovered through fuzz testing using American Fuzzy Lop,
cannam@48: which identified the problem as a "hang", although in fact the test case just
cannam@48: took a very long time to complete. We are incorporating testing with AFL into
cannam@48: our release process going forward.