[AaronFriel]

It's an incredible achievement, though I worry about the use of an unproven language (Zig) that lacks memory safety by design. JavaScript runtimes, especially those with JITs, have been plagued by vulnerabilities from memory safety, type confusion, and data races.

Node.js, despite being based on V8, is still susceptible independently of V8 and introduces its own vulnerabilities. It's not sufficient for the runtime to be secure, but the new facilities Bun provides must also be vetted.

Bun/Oven are new, and similar in position to Node. Here are the hard questions I'd ask if I were on a security team and asked to review adopting Bun:

1. Will Oven adopt a security policy for Bun? (https://github.com/oven-sh/bun/security)

2. What measures is Oven taking to proactively detect and mitigate vulnerabilities? (e.g.: fuzzing, audits, bug bounties)

3. Will Oven support Zig development to avoid an existential risk in upstream vulnerabilities?

[Jarred]

> 1. Will Oven adopt a security policy for Bun? (https://github.com/oven-sh/bun/security)

Yes.

> 2. What measures is Oven taking to proactively detect and mitigate vulnerabilities? (e.g.: fuzzing, audits, bug bounties)

Fuzzing will begin soon. Regular security audits will happen around the 1.0 release. Bug bounty seems like a good idea, but it's too early today to know when this will start.

> 3. Will Oven support Zig development to avoid an existential risk in upstream vulnerabilities?

Yes. Oven will donate to Zig Software Foundation.

More broadly - I think about all of this a lot, but until now Bun has been mostly the work of just me. Bun is still very early - there's a lot that's just not implemented yet.

[AaronFriel]

Thanks for answering Jarred, and I appreciate your answers given the early stage you're at. Runtime diversity in Node is quite exciting, and I'm sure you've more interesting challenges ahead than just security.

I look forward to seeing what you can make of it with Oven.

[brundolf]

Worth clarifying that Bun isn't a from-scratch JS runtime, it's a wrapper around JavaScriptCore (WebKit's JS engine), like Node is around V8

As you say, there's still plenty of room for vulnerabilities in the parts it does implement, and Zig isn't strictly memory-safe. However, Zig has lots of modern features like optional-types that help quite a bit with avoiding memory errors: https://www.scattered-thoughts.net/writing/how-safe-is-zig/

Which is to say your question is definitely valid, but there are also reasons to think this isn't as huge a concern as it might seem

[jamil7]

> Worth clarifying that Bun isn't a from-scratch JS runtime, it's a wrapper around JavaScriptCore (WebKit's JS engine)

Does this mean you could potentially run some Node code on iOS?

[andrei]

> 2. What measures is Oven taking to proactively detect and mitigate vulnerabilities? (e.g.: fuzzing, audits, bug bounties)

We're huge fans of bun at Fuzzbuzz (waiting for it to get a bit more production-ready). If Jarred's interested, we'd be happy to donate some compute to support fuzzing Bun.

<hn username> @ fuzzbuzz.io

[TakeBlaster16]

> though I worry about the use of an unproven language

Maybe this will be the company that proves it :)

[naikrovek]

I am fairly confident that Zig does not lack memory safety by design; from what I understand, the language as a whole isn't even finished, and the memory safety design isn't like a GC'd language or like Rust, so people assume there isn't memory safety when in reality it is at least partially implemented.

[AaronFriel]

I'm afraid "partially implemented" memory safety is also widely known in the offensive security industry as "not memory safe". Many people have fooled themselves into thinking there is a gradient with safer C++ abstractions, libraries in C, custom allocators, static analyzers, valgrind, etc.

[naikrovek]

the entire language is partially implemented yet you are judging it as if it is complete and set in stone.

Rust isn't even memory safe if you want to be THIS pedantic about it. the unsafe keyword exists in Rust, and it is often used.

[nicoburns]

> Rust isn't even memory safe if you want to be THIS pedantic about it. the unsafe keyword exists in Rust, and it is often used.

In practice, Rust seems to be much safer. I've seen Jarred talking about segfaults in Bun. Those are practically unheard of in Rust programs, and indicative of the possibility of quite serious security vulnerabilities.

[AaronFriel]

Unsafe is perhaps poorly named, and several Rust core team members have commented as such. It doesn't mean memory unsafe, it means "not checked by the compiler".

Safe APIs that contain unsafe blocks must still be proven correct, via Miri, a model checker, formal proof, etc. Any safe functions that violate memory safety are considered bugs. The limited number of unsafe functions exist as helpers to build safe APIs when the compiler's borrower checker is insufficient.

What this means is that to verify memory safety, one can restrict their search to unsafe blocks. And hypothetically if the Rust compiler were to get much smarter, it should be possible to prove to the compiler that those blocks are safe (via theorem prover, perhaps?) and remove the "unsafe" declaration.

In most languages, there is no such distinction between the "memory safe" common set users ought to use and the subset that has to be verified independently. Neither Zig, C, C++, nor even Go have a clear delineation between safe and unsafe code.

[naikrovek]

> Unsafe is perhaps poorly named, and several Rust core team members have commented as such. It doesn't mean memory unsafe, it means "not checked by the compiler".

That's lack of memory safety when your memory safety work is done during compilation, as is the case with Rust.

[ksec]

Last time an Open Source project was using UnSafe it was getting attacked by Rust Evangelism Task Force.

[rileyphone]

Is there not a gradient though? Are C++ smart pointers equally as bad as regular old malloc? Can safer abstractions not render most buffer overflows impossible?

[AaronFriel]

I misspoke. Yes, security is on a gradient and the things I've listed have caught and prevented many, many bugs, but memory safety is a binary proposition. Those things have not made C++ "memory safe".

[cocoto]

There is definitely a gradient in safety and almost everybody agree with that. What is controversial is how much safety you actually need.

[throwawaymaths]

And it's not clear that safety has to be in the compiler: it could be in a static analysis tool, for example.

[AaronFriel]

I misspoke, there is a gradient in safety, but "memory safe" is binary.

[_vvhw]

There is in fact a spectrum with respect to memory safety. For example, temporal vs spatial safety.

Furthermore, no language is “memory safe” in the absolute sense. For example, not even the borrow checker can protect you from buffer bleeds.

[AaronFriel]

Despite the "How Safe is Zig"[1] blog post, it's false that there is a spectrum. A lack of temporal safety implies a lack of spatial safety, and vice versa.

If one can use a use-after-free, invalid write, time of check-time of use error to write a byte to an invalid location, the program's data structures are now in an inconsistent state, violating invariants required for "spatial safety" such as objects being the correct type, buffers and lengths being paired together correctly, etc.

Likewise, if one can accomplish a buffer overflow, a spatial safety violation, or an out of bounds write, then by definition they've made temporal violations as well. Writing objects out of bounds or arbitrary heap writes imply data races.

Offensive security folks use gadgets that exploit one to accomplish the other, as needed.

[1] https://www.scattered-thoughts.net/writing/how-safe-is-zig/

[jmartin2683]

Agreed. Rust is a far more reasonable/obvious choice.