Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20231003203853.GA24745@openwall.com>
Date: Tue, 3 Oct 2023 22:38:53 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Andreas Kling <kling@...enityos.org>
Subject: Wuffs (was: CVE-2023-5217: Heap buffer overflow in vp8 encoding in libvpx)

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@...ecat.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

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.