How Cloudflare Images addressed the aCropalypse vulnerability

blog.cloudflare.com

59 points·jgrahamc··5 comments

FTA: // Infallible: We've definitely consumed 4 bytes

... erm, wasn't the original issue created by an undocumented change to File API semantics?

Not that I know how their backend works, and I'm sure their consume function is all super robust with every edge-case possible covered in the test suite..... but "Infallible" oh dear... :P

> The Images team addressed the vulnerability in a way that didn’t require any changes to the original images or cause any increased latency or regressions for customers.

How do you add additional synchronous checks in the code without increasing latency? It might be negligible, but it isn't nothing.

> we just have to check that once we have consumed the end-of-image marker all of the input has been consumed. In our proxy we use an in-memory buffer as input, so we can check that there are no bytes left in the buffer:

> As the format is so regular, it’s easy to write a separate parser that just reads the prelude, loops through the chunks until we see IEND, and then checks if we have any bytes left. We can perform this check after decoding the image with lodepng, as this allows us to skip validating the checksums as lodepng has already checked them for us

Again, those checks might be negligible, but aren't nothing. The JPEG check looks like one extra check in existing code, so that's truly almost nothing, but the PNG check introduced an extra parsing step of the file.

Assume it's 0.1ms slowdown per-image ?

Reply on news.ycombinator.com