4 ms·

Zig is a C-like language that isn't memory safe. A UAF bug looks the same as it does in C where you manually call the allocator to get a block of memory, manual

Zig is a C-like language that isn't memory safe. A UAF bug looks the same as it does in C where you manually call the allocator to get a block of memory, manually free it, then try to perform an access via a pointer to it.

jorangreef 6y ago
To be fair, Zig provides a spectrum of memory safety as the comparison table in the post makes clear. Sure, it isn't 100% memory safe, and especially not around UAF, but it's still orders of magnitude safer than C. In the safety department, it's not at all a "C-like language" in that respect. It's a massive leap forward.
- tptacek 6y ago
  Type confusion and memory lifecycle flaws are probably the dominant source of exploitable vulnerabilities at this point. I'm surprised to see it suggested that Zig is weak to them.
  - jorangreef 6y ago
    Hey Thomas, I would have thought you would have said that at this point JavaScript or Postel's law were probably the dominant source of exploitable vulnerabilities. You're right though, Zig is weak to them, but it's not all or nothing as with C. It's a spectrum, and having spent some time with the language, I think that for Zig's goals, it makes the right set of trade-offs.
    - tptacek 6y ago
      Exploitable memory corruption vulnerabilities, sorry. But I think this page may be overstated? Again: I don't know anything about Zig, but I sure know how a UAF bug works. :) And it doesn't look like Zig is meaningfully susceptible to them? You an crash a Zig program with a UAF, but the actual vulnerability wants more than the crash: it wants the program making uncontrolled writes to live memory used elsewhere in the program, which is a condition I don't think is present in Zig as it's being described. If that's the case, that bodes poorly for the claim that Zig is susceptible to C/C++-style double free vulnerabilities, too. It would be genuinely weird to see a new language rolling out that had C/C++'s UAF problem. (As was pointed out elsewhere: if you're using an external allocator, or the `c_allocator`, all bets are off. But so is unsafe code in Rust, I guess?)
  - jamii 6y ago
    I wasn't able to find many breakdowns of actual exploits by root cause. Do you have additional sources that I could add to the article?

jorangreef 6y ago

To be fair, Zig provides a spectrum of memory safety as the comparison table in the post makes clear. Sure, it isn't 100% memory safe, and especially not around UAF, but it's still orders of magnitude safer than C. In the safety department, it's not at all a "C-like language" in that respect. It's a massive leap forward.

tptacek 6y ago
Type confusion and memory lifecycle flaws are probably the dominant source of exploitable vulnerabilities at this point. I'm surprised to see it suggested that Zig is weak to them.
- jorangreef 6y ago
  Hey Thomas, I would have thought you would have said that at this point JavaScript or Postel's law were probably the dominant source of exploitable vulnerabilities. You're right though, Zig is weak to them, but it's not all or nothing as with C. It's a spectrum, and having spent some time with the language, I think that for Zig's goals, it makes the right set of trade-offs.
  - tptacek 6y ago
    Exploitable memory corruption vulnerabilities, sorry. But I think this page may be overstated? Again: I don't know anything about Zig, but I sure know how a UAF bug works. :) And it doesn't look like Zig is meaningfully susceptible to them? You an crash a Zig program with a UAF, but the actual vulnerability wants more than the crash: it wants the program making uncontrolled writes to live memory used elsewhere in the program, which is a condition I don't think is present in Zig as it's being described. If that's the case, that bodes poorly for the claim that Zig is susceptible to C/C++-style double free vulnerabilities, too. It would be genuinely weird to see a new language rolling out that had C/C++'s UAF problem. (As was pointed out elsewhere: if you're using an external allocator, or the `c_allocator`, all bets are off. But so is unsafe code in Rust, I guess?)
- jamii 6y ago
  I wasn't able to find many breakdowns of actual exploits by root cause. Do you have additional sources that I could add to the article?