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.