oss-sec mailing list archives
Wuffs (was: CVE-2023-5217: Heap buffer overflow in vp8 encoding in libvpx)
From: Solar Designer <solar () openwall com>
Date: Tue, 3 Oct 2023 22:38:53 +0200
On Fri, Sep 29, 2023 at 12:35:07PM -0400, Demi Marie Obenour wrote:
On Thu, Sep 28, 2023 at 05:10:09PM -0700, nightmare.yeah27 () aceecat org wrote:On Thu, Sep 28, 2023 at 04:42:33PM -0400, Demi Marie Obenour wrote:How long will it take for corporations to accept that writing media
Demi Marie, for further occasions I'd appreciate it if such tangential topics be started in their own threads (OK to refer to current context, but not mix with it in same thread) and be worded non-provocatively. Luckily, we got quite reasonable follow-ups this time - much better than typical (anti-)Rust flamewars on tech news sites. So I don't really complain. But I was reluctant and worried about accepting the above.
codecs in C, C++, or any other memory-unsafe language is a fundamentally bad idea, and that it is better to rewrite the codecs in a safe language (such as Wuffs or Rust) than to try to secure the existing ones?Wouldn't the low-level code have to ultimately depend on unsafe Rust modules, or similar feature in other safe language?In Wuffs, every memory access is checked for safety at compile-time, and that includes being in-bounds. If the compiler cannot prove that every access is safe, the code will not compile. There are no bounds checks at runtime. Interfacing with hardware accelerators obviously will need unsafe code, but my understanding is that most vulnerabilities are in various parsers or in the code the accelerators replace, not in the code that interfaces with the accelerators.
The mention of Rust triggered people, but let's not overlook Wuffs, "Wrangling Untrusted File Formats Safely": https://github.com/google/wuffs I was actually unaware of Wuffs, so I appreciate learning of it. As I understand, it's a language currently transpiled to C: https://github.com/google/wuffs/tree/main/release/c
Wuffs the Library ships as a "single file C library", also known as a "header file library". To use that library in your C/C++ project, you just need to copy one file from this directory, or otherwise integrate that one file into your build system.
The C file containing all of the parsers currently implemented in Wuffs is around 2 MB in size. That's a lot, but then there are many parsers: https://github.com/google/wuffs/tree/main/std $ ls std/ adler32 bmp bzip2 cbor crc32 deflate gif gzip jpeg json lzw netpbm nie png tga wbmp zlib Curiously, some of these optionally use SIMD - all while retaining the language's safety guarantees? Even though this looks like a Google project, I think a better place for its initial adoption could be a hobbyist OS and web browser project like what Andreas Kling is working on. I'm not saying this is necessarily a good idea, it just feels more realistic to me. Alexander
Current thread:
- Wuffs (was: CVE-2023-5217: Heap buffer overflow in vp8 encoding in libvpx) Solar Designer (Oct 03)