3 ms·

From the browser makers' point of view there's quite a bit of risk with introducing a new image format. libjxl is written in C++ so undoubtedly will be full of

by rwmj 3y ago

From the browser makers' point of view there's quite a bit of risk with introducing a new image format. libjxl is written in C++ so undoubtedly will be full of undiscovered security issues. I'm sure that someone will write a decoder in a safer language, but that work still needs to be done and/or finished, and then integrated with the browser. At the same time there are to 5 significant places probably 0% of websites that host .jxl files. So at the start it's all downside and almost no upside. (Chicken and egg problem here of course which is no one will create the websites until there is wide browser support.)

cesarb 3y ago
> libjxl is written in C++ so undoubtedly will be full of undiscovered security issues. There's the WebAssembly sandboxing trick (https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again...) which might mitigate that, but an image decoder might fall into the "too performance-sensitive to accept the modest overhead incurred" case.
apichat 3y ago
Two rust implementation projects : https://github.com/tirr-c/jxl-oxide https://github.com/tirr-c/jxl-oxide https://github.com/libjxl/jxl-rs https://github.com/libjxl/jxl-rs
- rwmj 3y ago
  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.
  - croes 3y ago
    Isn't that true for the other new formats they support too? Why single out JPEG XL?
    - rwmj 3y 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. WebP is one of the most recently added image formats, and it had zero day exploits as recently as 6 months ago.
      - cubefox 3y 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.
        solardev 3y ago
        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.
        cubefox 3y ago
        When deciding whether A is better than B, it is irrelevant to point out problems that apply to A and B equally.
        mynameisvlad 3y ago
        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.
BlackLotus89 3y ago
https://github.com/niutech/jxl.js https://github.com/niutech/jxl.js a javascript polyfill taken from the main page https://jpegxl.info/ https://jpegxl.info/ There are other decoders [0] written in a "safe language" (rust) listed as well. So no there are many "safe" implementations [0] https://github.com/tirr-c/jxl-oxide https://github.com/tirr-c/jxl-oxide
pmarreck 3y ago
Aren't there C++ static code analysis tools at this point that might mitigate such risks?
- deleted 3y ago
  [deleted]
zokier 3y ago
> If having a high quality Rust decoder implementation would arise as the only gating factor for choosing JPEG XL into interop 2024, the JPEG XL developer team in Google Research can deliver such by the end of Q2 2024 > We have tested conformance of the jxl-oxide decoder (which is implemented in Rust) and it is a fully conforming alternative implementation of JPEG XL. It correctly decodes all conformance test bitstreams and passes the conformance thresholds described in ISO/IEC 18181-3. https://github.com/web-platform-tests/interop/issues/430 https://github.com/web-platform-tests/interop/issues/430
amluto 3y ago
It takes some effort to implement, but Google has WUFFS for almost exactly this purpose: https://github.com/google/wuffs https://github.com/google/wuffs
- rwmj 3y ago
  Yes this is pretty great actually.

by rwmj 3y ago

cesarb 3y ago

> libjxl is written in C++ so undoubtedly will be full of undiscovered security issues. There's the WebAssembly sandboxing trick (https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again...) which might mitigate that, but an image decoder might fall into the "too performance-sensitive to accept the modest overhead incurred" case.

apichat 3y ago

Two rust implementation projects : https://github.com/tirr-c/jxl-oxide https://github.com/tirr-c/jxl-oxide https://github.com/libjxl/jxl-rs https://github.com/libjxl/jxl-rs

rwmj 3y ago
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.
- croes 3y ago
  Isn't that true for the other new formats they support too? Why single out JPEG XL?
  - rwmj 3y 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. WebP is one of the most recently added image formats, and it had zero day exploits as recently as 6 months ago.
    - cubefox 3y 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.
      - solardev 3y ago
        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.
        cubefox 3y ago
        When deciding whether A is better than B, it is irrelevant to point out problems that apply to A and B equally.
        mynameisvlad 3y ago
        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.

BlackLotus89 3y ago

https://github.com/niutech/jxl.js https://github.com/niutech/jxl.js a javascript polyfill taken from the main page https://jpegxl.info/ https://jpegxl.info/ There are other decoders [0] written in a "safe language" (rust) listed as well. So no there are many "safe" implementations [0] https://github.com/tirr-c/jxl-oxide https://github.com/tirr-c/jxl-oxide

pmarreck 3y ago

Aren't there C++ static code analysis tools at this point that might mitigate such risks?

deleted 3y ago
[deleted]

zokier 3y ago

> If having a high quality Rust decoder implementation would arise as the only gating factor for choosing JPEG XL into interop 2024, the JPEG XL developer team in Google Research can deliver such by the end of Q2 2024 > We have tested conformance of the jxl-oxide decoder (which is implemented in Rust) and it is a fully conforming alternative implementation of JPEG XL. It correctly decodes all conformance test bitstreams and passes the conformance thresholds described in ISO/IEC 18181-3. https://github.com/web-platform-tests/interop/issues/430 https://github.com/web-platform-tests/interop/issues/430

amluto 3y ago

It takes some effort to implement, but Google has WUFFS for almost exactly this purpose: https://github.com/google/wuffs https://github.com/google/wuffs

rwmj 3y ago
Yes this is pretty great actually.