4 ms·
UAF in zig. It still kind of sucks: https://www.youtube.com/watch?v=4nVhByP-npU&t=11820s https://www.youtube.com/watch?v=4nVhByP-npU&t=11820s
by dnautics 6y ago
UAF in zig. It still kind of sucks:
https://www.youtube.com/watch?v=4nVhByP-npU&t=11820s https://www.youtube.com/watch?v=4nVhByP-npU&t=11820s
- tptacek 6y agoOk, but that video suggests that Zig's allocator wires the program to segfault if you access the freed memory. With a 64 bit address space I guess you can do this perpetually?
- dnautics 6y agoSort of, I think if you do multiple allocates, though the best you can do is overwriting with the poison value 0b10101010...
- jamii 6y agoThe author gives more detail in this thread - https://lobste.rs/s/v5y4jb/how_safe_is_zig#c_vddk9j https://lobste.rs/s/v5y4jb/how_safe_is_zig#c_vddk9j
- tptacek 6y agoThat's what I figured: the 64 bit address space ensures that they're just never going to reuse address space. Which, in turn, means that C-style UAFs are unlikely to be an issue. I think this page should probably capture that.
- jamii 6y agoI mentioned it in the next section: > The standard library includes a set of allocators which don't reuse allocations, preventing use-after-free, and which catch double-free. I'm not clear yet on how high the runtime and memory overhead are though, which will dictate when it is practical to use these. I didn't include it in the table because I'm not yet convinced that the overhead will be low enough that people will actually ship software using those allocators. (All the zig programs I've written so far use the libc allocator and are definitely susceptible to UAF) Perhaps I'll spend some time measuring it this week and post an update.
- dnautics 6y agoyou can write tests using it, though, and that has the added side effect of nudging you to write tests in general.