5 ms·

Using Rust may be the easiest option because there are existing crates for decoding GIF files (and other image formats) for example: https://crates.io/crates/i

Using Rust may be the easiest option because there are existing crates for decoding GIF files (and other image formats) for example: https://crates.io/crates/image https://crates.io/crates/image It should be straightforward to swap out the vulnerable C library with a thin wrapper around the above crate.

pjmlp 7y ago
The safest option would have been to use JNI to call Android hardened codecs instead of using their own decoding library in process.
- pcwalton 7y ago
  But it was pointed out upthread that animated GIFs aren't fully supported by the native Android libraries. So Rust would actually be a reasonable solution here. It's true that there are costs associated with using Rust in the build process and so forth, but WhatsApp is trying to be a secure messenger and is FAANG-backed. The challenges can be overcome.
  - pjmlp 7y ago
    Indeed, however Android does support other image formats with animation, which could have been another solution, much cheaper than introducing yet another language not directly supported by the OS SDK tooling.
    - bluejekyll 7y ago
      > not directly supported by the OS SDK tooling. If that's an issue, I bet the Rust community is interested in making it easier and better supported.
      - pjmlp 7y ago
        Think about the Android development experience, using Android Studio, Gradle + CMake/ndk-build, mixed mode debugging across Java/Kotlin and native, Android Studio project templates for native code, packaging Android libraries, Bundles and Instant Apps, NDK APIs and Google libraries for Android intended for NDK consumption like Oboe. This are the expectations that any external language should meet versus what platform languages offer out of the box.
        littlestymaar 7y ago
        I haven't done any android dev in a while so it may have changed in between, but it sounds that your expectations are higher than what the Android experience looks like when JNI is involved.
        pjmlp 7y ago
        My expectations are what an Android developer using Studio 3.5 with NDK r20 would expect. While the experience is still found lacking versus what iOS or UWP tooling are capable of, it still is much better than any third party language integration.
    - Diggsey 7y ago
      Changing to a different image format may not be possible because WhatsApp still needs to show historical images, and these images are not stored on a central server where they can be migrated. Also, it's called the "Android NDK" and not the "Android C SDK" - a big part of what the NDK gives you is not C-specific. It makes almost no difference whether you compile your code with GCC vs rustc, at the end of the day you're creating a native shared library and loading it from a java application. For example, these instructions from 2017 show how little work is involved https://mozilla.github.io/firefox-browser-architecture/experiments/2017-09-21-rust-on-android.html https://mozilla.github.io/firefox-browser-architecture/exper... and support has only improved since then. Using static analysis tooling on C/C++ code is more work than the above to set up, so I really do believe that Rust is the easiest way to reduce the chance of these kinds of bugs happening again.
      - deleted 7y ago
        [deleted]
      - pjmlp 7y ago
        Then they could add a memory safe Java library dependency like Glide. Yes it is called the NDK and the workflow that you describe doesn't support the bullet points I described. If Rust wants to be embraced by Android developers it needs to up its game in Android Studio tooling, Binder generation and FFI integration. Those instructions from 2017 are completely outdated given Android 3.5 and NDK r20. GCC is no longer around, C++ support has improved quite substantially, static analysis tooling is integrated into NDK, Android Studio 3.7 (planned for next year) will bring support for mixed mode NDK libraries in AAR format.
layoutIfNeeded 7y ago
Sure, the “easiest” option is bringing in a whole new language and its toolchain just to decode gifs. Lol!
stevekablink 7y ago
Exactly! This software should be re-written in Rust, ASAP! Any software that's mission critical at all shouldn't be written in anything but. Now that Rust's technology exists, it's almost criminal not to use it.
- _bxg1 7y ago
  Much as I love Rust, some of its advocates have a tendency to drop into conversations like this and oversimplify the situation, suggesting it be immediately used for everything under the sun, with limited context. There are many factors that go into deciding whether to integrate a new language into your project. For example: - Tooling - Build process - Library support - Developer expertise - Interop Any of these can cause lots of friction, especially when your codebase has more than one language. Not to mention hiring challenges, man-hours required to do a conversion, etc. That's not to say it's automatically the wrong decision, but it's certainly not a simple one. The case may be stronger on a greenfield project - though some of the above still applies - but then in many cases you may care more about iteration speed than performance, landing you with a GCed language. Edit: I've been informed that the parent comment was trolling
  - adwn 7y ago
    You're inadvertently replying to a troll account impersonating steveklabnik [1] (note the position of the 'l' and 'n'). Please don't judge the Rust community based on such idiots – most of us are quite reasonable and don't go around proselytizing others :-) [1] https://news.ycombinator.com/user?id=steveklabnik https://news.ycombinator.com/user?id=steveklabnik
    - _bxg1 7y ago
      Ah- well then I would say the fact that I couldn't distinguish the post from other, real comments I've seen on HN just reinforces my point ;) But yeah, I personally know those are a minority of the Rust community; I'm in the same boat where I don't want the whole thing being judged by a vocal minority.

pjmlp 7y ago

The safest option would have been to use JNI to call Android hardened codecs instead of using their own decoding library in process.

pcwalton 7y ago
But it was pointed out upthread that animated GIFs aren't fully supported by the native Android libraries. So Rust would actually be a reasonable solution here. It's true that there are costs associated with using Rust in the build process and so forth, but WhatsApp is trying to be a secure messenger and is FAANG-backed. The challenges can be overcome.
- pjmlp 7y ago
  Indeed, however Android does support other image formats with animation, which could have been another solution, much cheaper than introducing yet another language not directly supported by the OS SDK tooling.
  - bluejekyll 7y ago
    > not directly supported by the OS SDK tooling. If that's an issue, I bet the Rust community is interested in making it easier and better supported.
    - pjmlp 7y ago
      Think about the Android development experience, using Android Studio, Gradle + CMake/ndk-build, mixed mode debugging across Java/Kotlin and native, Android Studio project templates for native code, packaging Android libraries, Bundles and Instant Apps, NDK APIs and Google libraries for Android intended for NDK consumption like Oboe. This are the expectations that any external language should meet versus what platform languages offer out of the box.
      - littlestymaar 7y ago
        I haven't done any android dev in a while so it may have changed in between, but it sounds that your expectations are higher than what the Android experience looks like when JNI is involved.
        pjmlp 7y ago
        My expectations are what an Android developer using Studio 3.5 with NDK r20 would expect. While the experience is still found lacking versus what iOS or UWP tooling are capable of, it still is much better than any third party language integration.
  - Diggsey 7y ago
    Changing to a different image format may not be possible because WhatsApp still needs to show historical images, and these images are not stored on a central server where they can be migrated. Also, it's called the "Android NDK" and not the "Android C SDK" - a big part of what the NDK gives you is not C-specific. It makes almost no difference whether you compile your code with GCC vs rustc, at the end of the day you're creating a native shared library and loading it from a java application. For example, these instructions from 2017 show how little work is involved https://mozilla.github.io/firefox-browser-architecture/experiments/2017-09-21-rust-on-android.html https://mozilla.github.io/firefox-browser-architecture/exper... and support has only improved since then. Using static analysis tooling on C/C++ code is more work than the above to set up, so I really do believe that Rust is the easiest way to reduce the chance of these kinds of bugs happening again.
    - deleted 7y ago
      [deleted]
    - pjmlp 7y ago
      Then they could add a memory safe Java library dependency like Glide. Yes it is called the NDK and the workflow that you describe doesn't support the bullet points I described. If Rust wants to be embraced by Android developers it needs to up its game in Android Studio tooling, Binder generation and FFI integration. Those instructions from 2017 are completely outdated given Android 3.5 and NDK r20. GCC is no longer around, C++ support has improved quite substantially, static analysis tooling is integrated into NDK, Android Studio 3.7 (planned for next year) will bring support for mixed mode NDK libraries in AAR format.

layoutIfNeeded 7y ago

Sure, the “easiest” option is bringing in a whole new language and its toolchain just to decode gifs. Lol!

stevekablink 7y ago

Exactly! This software should be re-written in Rust, ASAP! Any software that's mission critical at all shouldn't be written in anything but. Now that Rust's technology exists, it's almost criminal not to use it.

_bxg1 7y ago
Much as I love Rust, some of its advocates have a tendency to drop into conversations like this and oversimplify the situation, suggesting it be immediately used for everything under the sun, with limited context. There are many factors that go into deciding whether to integrate a new language into your project. For example: - Tooling - Build process - Library support - Developer expertise - Interop Any of these can cause lots of friction, especially when your codebase has more than one language. Not to mention hiring challenges, man-hours required to do a conversion, etc. That's not to say it's automatically the wrong decision, but it's certainly not a simple one. The case may be stronger on a greenfield project - though some of the above still applies - but then in many cases you may care more about iteration speed than performance, landing you with a GCed language. Edit: I've been informed that the parent comment was trolling
- adwn 7y ago
  You're inadvertently replying to a troll account impersonating steveklabnik [1] (note the position of the 'l' and 'n'). Please don't judge the Rust community based on such idiots – most of us are quite reasonable and don't go around proselytizing others :-) [1] https://news.ycombinator.com/user?id=steveklabnik https://news.ycombinator.com/user?id=steveklabnik
  - _bxg1 7y ago
    Ah- well then I would say the fact that I couldn't distinguish the post from other, real comments I've seen on HN just reinforces my point ;) But yeah, I personally know those are a minority of the Rust community; I'm in the same boat where I don't want the whole thing being judged by a vocal minority.