Cloudflare deserves some more credit for how transparent they were about the issue, to be fair though, I think it is unlikely they knew about the leak, given the rarity and impactfulness. I would chalk the empty buffer masking the issue up to coincidence.
Assumptions:
- The graph for "email obfuscation" vs. "bug occurrence" at 2:51. This was added to illustrate that the bug was being triggered by this feature. They did not have a convenient graph that told them when the bug was being triggered.
- The "crossroads" mentioned at 3:55 probably did not happen. Just to add drama/plot.
- Explanation of why fhold is called within the finishing action of script_consume_attr is my best guess 7:50
- The history behind the empty last buffer was never explained. But I assume that some existing Module A would originally feed data to the Ragel parser. Module A still existed, and still continued to output this empty last buffer, but now cf-html can stand between Module A and the existing Ragel parser. Here, cf-html would consume Module A's data + the empty last buffer with no issues, but it's output would no longer include the dummy buffer. This output can then be taken in by the Ragel parser.
- Whether or not Cloudflare modified the compiled C code is unknown/never mentioned. There must be a reason that Ragel chooses to use == for the buffer end check rather than ≥, and semantically, == makes more sense if it checks for the buffer end with every iteration, which should make buffer overrunning impossible.
- Technically in the strictest sense this is a "buffer over-read" as opposed to an "overflow" or "overrun" but the Wikipedia page for Cloudbleed says "overflow" so w/e
Cloudflare deserves some more credit for how transparent they were about the issueCloudflare deserves some more credit for how transparent they were about the issue
- Whether or not this bug going unnoticed/discovered by hackers first would've "blown up the internet" is arguable