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: