Hacker News Reader

Hacker News

Comment by apichat | Hacker News Reader

Parent Full thread

apichat

Two rust implementation projects :

https://github.com/tirr-c/jxl-oxide

https://github.com/libjxl/jxl-rs

View on HN

Unfortunately a Rust implementation doesn't solve everything that could go wrong in a browser. You need to think about amongst other things: total memory that an image could allocate, safety of network references (if the format allows that, like SVG or XML), any kind of unbounded processing or memory usage caused by the image (such as a "zip bomb"), and what could possibly go wrong for every corner case in the standard. The Wikipedia page says that JPEG XL supports up to 1 terapixel images, which is unlikely to be a good idea for a browser even if it's handled in a memory safe way.

A while back I fuzz tested qemu's handling of various different disk image formats (I know, a different type of "image", but bear with me!) I found many cases where qemu could consume huge amounts of memory or CPU time on some inputs. Often times the inputs were quite small too, allowing nasty amplification attacks. As a result of this standard advice for clouds that allow you to upload untrusted images is to decode in a separate process. That process is protected with ulimits, so it will die, rather than trying to allocate all memory in the machine or consume huge amounts of CPU.

Isn't that true for the other new formats they support too?

Why single out JPEG XL?

It is true about other formats, but those have been in browsers for a long time so by now we have patched most of the exploits.

WebP is one of the most recently added image formats, and it had zero day exploits as recently as 6 months ago.

> It is true about other formats, but those have been in browsers for a long time so by now we have patched most of the exploits.

The current debate is about JPEG XL vs AVIF. Advantages of old image formats are not relevant here.

How are they not irrelevant? This is a cyclical problem browsers and OSes have dealt with many times before, and JPEGXL will hardly be the last time. It's a fundamentally challenging situation that applies to the newest image codec as much as it does to old ZIP files or hostile PDFs.

There will always be some new format with some advantage or another, but safely parsing complex user generated content just isn't trivial, so every one of these is both a cost benefit analysis on its own merits but also a chance to reflect on historical implementations, vulnerabilities, and lessons learned.

When deciding whether A is better than B, it is irrelevant to point out problems that apply to A and B equally.

If the argument is between two new formats, how are old formats at all relevant? The issues you outlined are faced by both (or any) new format so is essentially moot in the context of this conversation.

Did I miss something? The title and article are mostly about JPEG XL. What's the "both" in this? JPEG XL is the newest and has poor support. AVIF is mentioned offhandedly in that article, but it's a little older and still doesn't have great support. WebP is even older and also has occasional issues.

The image formats past WebP offer very minor improvements but have big potentials for new zero-days. I don't think it's wrong to play it safe and/or just don't implement them.

>it had zero day exploits as recently as 6 months ago

That not a measure of security.

How many malware exists for MacOS compared to Windows. Does that mean MacOS is safer?

You could easily argue the other way around that WebP and say has more undiscovered exploits.

> Why single out JPEG XL?

Hopefully it isn't singled out, and any prospective support for a new image format gets the same scrutiny.

The question is different for any image format that is already supported, because removing it breaks the web to the extent the format is being used. That's really an argument to be particularly careful about adding support for a new format: once it is widely available for a while it is almost impossible to remove. This is a one-way decision (unless it's barely used, in which case there wasn't a good reason to add it in the first place).

A safe Rust implementation solves the biggest problems.

It's definitely better than no memory safety, but not sufficient to deal with all the cases that a browser (or anything parsing untrusted data from the internet) needs to think about.

Chrome already handles excessive CPU or memory use by a tab, and I very much doubt the format supports urls (and it would be trivial to check).

Nothing you've said should be an issue. I expect really they just don't want "their" formats to be obsoleted.

Reply on news.ycombinator.com