WhatsUp is an incredibly popular messaging application. As a result, the authors decided to fuzz it with AFL. In particular, they fuzzed a few image types and filters. While doing the blackbox fuzzing of these functinos the authors got a crash in one of the filters.
After validating on the crash on a phone app and crazy amount of reverse engineering the crash, they found the root cause. When dealing with the filters, there is an assumption that the source and destination filters have the same bytes per pixel.
When handling the height, stride (pixel size) and the width of a picture, the height is advanced by groups of 4. However, there is not always the case; what if the destination and source image have different pixel sizes. The code did not prepare for this! Only the source pixel size is actually checked.
Therefore, when a maliciously crafted source image has only 1 byte per pixel, the function tries to read and copy 4 times the amount of the allocated source image buffer, which leads to an out-of-bounds memory access. This OOB read could be used to steal secret information from the application, if setup properly. This could go in the other direction for a memory write as well.
The fix validates that the image format and uses the proper stride for the format. To trigger this bug, a user must use a specific filter on a specific image; this would require a self-attack or a substantial amount of reverse engineering to full off.
Overall, this is an interesting business logic bug that led to the wrong stride (pixel size) being used. I appreciated the exploit method, as it was not all about code execution (which is what most memory corruption bugs are). This reminded me a lot of Heartbleed as a result.