Comment by peter_d_sherman | Hacker News Reader

Comment by peter_d_sherman | Hacker News Reader

peter_d_sherman

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."

There were security flaws in the code that handled BMP files. These were revealed after the source code to Windows 2000 leaked.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=can-2004-0566

Also the iPhone TIF rendering bug famous for enabling jailbreakme

Let me rephrase:

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...).

But... all in all, doesn't surprise me...

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.

>When was the last time there was a serious vulnerability in major JPEG libs?

1) Kindly define "serious"...

2) Kindly define "major"...

Also... why can't you ask the question you pose:

"When was the last time there was a serious vulnerability in major JPEG libs?"

...with the words "serious" and "major" removed, i.e.:

"When was the last time there was a vulnerability in JPEG libs?"

?

As that might be a far better question if the generation of insight is desired...

?

The most recent high severity vulnerability I could find in libjpeg is CVE-2016-6702[0].

If you're willing to count libjpeg-turbo, there's also CVE-2020-17541[1].

For h.264, if you're willing to count Firefox or gstreamer, we're talking CVE-2022-3266 or CVE-2021-3185 (the latter is even critical)

[0]: https://nvd.nist.gov/vuln/detail/CVE-2016-6702

[1]: https://nvd.nist.gov/vuln/detail/CVE-2020-17541

Reply on news.ycombinator.com