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