5 ms·

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 t

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 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?

naikrovek 4y ago
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 4y ago
  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.
  - cocoto 4y ago
    There is definitely a gradient in safety and almost everybody agree with that. What is controversial is how much safety you actually need.
    - AaronFriel 4y ago
      I misspoke, there is a gradient in safety, but "memory safe" is binary.
      - _vvhw 4y ago
        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 4y ago
        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/ https://www.scattered-thoughts.net/writing/how-safe-is-zig/
        _vvhw 4y ago
        Thanks, that's a great insight! Does it follow that the fact that temporal violations could be used to violate runtime spatial checks, therefore means that spatial safety in itself is entirely without value? What are your thoughts also on buffer underflows? I ask since I take it you also work on offensive security.
        AaronFriel 4y ago
  - rileyphone 4y ago
    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 4y ago
      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".
      - deleted 4y ago
        [deleted]
  - naikrovek 4y ago
    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.
    - AaronFriel 4y ago
      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 4y ago
        > 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.
    - nicoburns 4y ago
      > 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.
    - 4y ago
andrei 4y ago
> 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
brundolf 4y ago
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/ 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 4y ago
  > 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?
Jarred 4y ago
> 1. Will Oven adopt a security policy for Bun? (https://github.com/oven-sh/bun/security 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 4y ago
  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.
jmartin2683 4y ago
Agreed. Rust is a far more reasonable/obvious choice.
TakeBlaster16 4y ago
> though I worry about the use of an unproven language Maybe this will be the company that proves it :)

naikrovek 4y ago

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 4y ago
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.
- cocoto 4y ago
  There is definitely a gradient in safety and almost everybody agree with that. What is controversial is how much safety you actually need.
  - AaronFriel 4y ago
    I misspoke, there is a gradient in safety, but "memory safe" is binary.
    - _vvhw 4y ago
      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 4y ago
        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/ https://www.scattered-thoughts.net/writing/how-safe-is-zig/
        _vvhw 4y ago
        Thanks, that's a great insight! Does it follow that the fact that temporal violations could be used to violate runtime spatial checks, therefore means that spatial safety in itself is entirely without value? What are your thoughts also on buffer underflows? I ask since I take it you also work on offensive security.
        AaronFriel 4y ago
- rileyphone 4y ago
  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 4y ago
    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".
    - deleted 4y ago
      [deleted]
- naikrovek 4y ago
  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.
  - AaronFriel 4y ago
    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 4y ago
      > 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.
  - nicoburns 4y ago
    > 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.
  - 4y ago

andrei 4y ago

> 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

brundolf 4y ago

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/ 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 4y ago
> 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?

Jarred 4y ago

> 1. Will Oven adopt a security policy for Bun? (https://github.com/oven-sh/bun/security 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 4y ago
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.

jmartin2683 4y ago

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

TakeBlaster16 4y ago

> though I worry about the use of an unproven language Maybe this will be the company that proves it :)