Observation: Uncompressed bitmaps, while bloated in terms of necessary bandwidth, still are provably the most secure form of bitmap -- just as uncompressed video (again, while super-bloaty and bandwidth intensive) would be...
That is, to abstract, our security issue exists because:
A) There is complex compression/decompression software/code;
B) To implement this compression/decompression -- there are one or more lookup tables in effect;
C) The software implementing those lookup tables and the decompression side of things were never properly fuzzed, bound-checked, and/or mathematically proven not to create out-of-bounds errors, that is, for every potential use of the lookup table to be guaranteed as correct mathematically given any possibility, any combination of data in an input stream.
Also -- Didn't stuff like this already happen in GIF and PNG formats? Weren't there past security vulnerabilities for those formats?
Isn't this just (I dare to say) -- computer history repeating itself ?
Point: Software Engineering Discipline:
If you as a Software Engineer implement a decompressor for whatever format (or hell, more broadly and generically something that uses lookup tables on incoming streams of data) -- then the "burden of proof" is on you, to prove (one way or another) that it does not have vulnerabilities.
Fuzzing can help, mathematics and inductive/deductive logic can help, testing can help, and paranoid coding (always bounds-checking array accesses, etc.) can help, running in virtual machines and other types of limited environments and sandboxes can help. Running as interpreted code (albeit slower) could help. Deferring decompression to other local network attached resources running in limited execution environments could help.
In short... a monumental challenge... summed up as:
"Prove that all code which uses lookup tables can not generate hidden/unwanted states."
Uncompressed bitmaps with absolutely NO extraneous unnecessary "handling code" (which would have existed in the case of the Windows BMP display code, if a security flaw was found in them...).
Also... many posters suggest use of Rust may be a solution...
It may turn out to be... but I think a more broader generalization of the language /compiler aspect of things may be:
Not so much to "use Rust", so much as "NOT to use C".
That is -- any library performing decompression of any sort (regardless of whether that decompression is related to visual images or not), if it uses C and lookup tables and implements decompression -- should at least be considered a potential source of future problems, and should (ideally) be migrated to a more memory-safe, bounds-checked language -- in the future.
Rust -- may or may not turn out to be this language...
Negatives for Rust -- large size and complexity of Rust's compiler source code.
Positives for Rust -- Rust's treatment of memory and bounds-checking.
Anyway, some thoughts on the language/compiler aspect of this...
Yes, but as counterargument: there are battle-tested compression formats that offer pretty-damned-good compression. If anything, this shows some questions of calculus when it comes to risk-vs-reward of embracing new standards for compression formats. When was the last time there was a serious vulnerability in major JPEG libs? Or even h.264, which is much newer? Yes, a .webp is like 2/3 the size of a similar JPEG, but for most people are JPEG image sizes a huge cause for concern? Once you're doing lossy compression you're already sacrificing fidelity for filesize so you don't see a lot of machine-crushing-huge JPEGs.
That is, to abstract, our security issue exists because:
A) There is complex compression/decompression software/code;
B) To implement this compression/decompression -- there are one or more lookup tables in effect;
C) The software implementing those lookup tables and the decompression side of things were never properly fuzzed, bound-checked, and/or mathematically proven not to create out-of-bounds errors, that is, for every potential use of the lookup table to be guaranteed as correct mathematically given any possibility, any combination of data in an input stream.
Also -- Didn't stuff like this already happen in GIF and PNG formats? Weren't there past security vulnerabilities for those formats?
Isn't this just (I dare to say) -- computer history repeating itself ?
Point: Software Engineering Discipline:
If you as a Software Engineer implement a decompressor for whatever format (or hell, more broadly and generically something that uses lookup tables on incoming streams of data) -- then the "burden of proof" is on you, to prove (one way or another) that it does not have vulnerabilities.
Fuzzing can help, mathematics and inductive/deductive logic can help, testing can help, and paranoid coding (always bounds-checking array accesses, etc.) can help, running in virtual machines and other types of limited environments and sandboxes can help. Running as interpreted code (albeit slower) could help. Deferring decompression to other local network attached resources running in limited execution environments could help.
In short... a monumental challenge... summed up as:
"Prove that all code which uses lookup tables can not generate hidden/unwanted states."