[<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.
