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