What prevents me from writing a wasm file with an arbitrary value for "depth" greater than CALLSTACK_SIZE (1024) and overflowing the buffer? (If the answer is "nothing", that's probably arbitrary code execution.)
I knew it would only be a matter of time before someone mentioned this, although I was actually expecting someone to mention a specific alternate language.
That's an unreasonable expectation. Security is not left to bug fixes. It is a skill developed by overall knowledge of the domain, and an explicit intent to be conscious of how what you write can be misused.
If someone can scan your repo for a problem this quickly, then youre not designing secure software, and that should be posted front and center at the top of the repo given that wasms entire purpose is machine independent code that is properly sandboxed from exploitation.
Doesn't mean the runtime needs to provide that sandbox. If the only thing in the process is the WASM runtime & the WASM code then you don't need the runtime to do any sandboxing - the kernel already did that for you.
I'm not sure I agree. If you can affect the state of the runtime in ways that are not intended to be possible by the WASM API, this breaks sandboxing requirements. Even if you can't break out of the current process (due to isolation provided by the kernel), you can still cause arbitrary code execution within the process.
> you can still cause arbitrary code execution within the process
You start with the ability to do arbitrary code execution, you don't have to find an exploit to do that. And since your WASM code is the only thing in the process, what is an exploit going to let you do that you couldn't already do anyway?
You seem to be confused. Arbitrary code execution is just the ability to run code. It is a security attack when a user that wasn't supposed to be able to run code can now run code. But WASM and JS runtimes would be literally useless if you didn't start with the ability to run arbitrary code. Their sole purpose is to run code. You feed them code, they run it. You were supposed to have the ability to run code, therefore arbitrary code execution is not an exploit here.
Maybe you're confusing it with privilege escalation, though? Or a sandbox escape? But FYI those aren't the same thing. At all.
Alternatively if the worst you've seen on HN is one person seemingly confusing arbitrary code execution with privilege escalation you must not be on HN very much.
which was forked from https://github.com/kanaka/wac
the kanaka project appears to be a generic platform project where as the grassel fork is targeting the esp32.
Given the small scope and some of the ideal use cases for this, it would be really great to have some objectives like being 100% asan, msan, ubsan-clean and passing valgrind. People will eventually ship stuff like this in IoT and that'll make it unlikely that security and bug patches will get deployed.
Writing large C projects without tools like valgrind is crazy! I guess in some situations it can be hard to set up (like kernel programming.) but user space software should always be written with it.
My personal experience is tools like valgrind will immediately shove stupid mistakes back in your face (rather than waiting a few days to realize the change you made is corrupting the heap in a way that eventually causes the program to crash.) and the result is not only better memory management in your project but also better memory management in future projects.
or written in a secure language without undefined behavior and without any "unsafe" code
like Rust or Safe Haskell.
IoT probably should be shipping code that uses static compiler checks as the first line of security defense rather than run-time checks like valgrind and asan.
PICO8 is in many ways less constrained than real-world microcontrollers, and the nature of the constraints is quite different. It simply isn't a meaningful comparison.
Even if this was rewritten in Lua, I'm pretty sure that you'd have to figure out how to get it under the token limit before you had to worry about running in 512k RAM.
It's strange that the readme says it requires 32 bit userspace tools.
Part of me is pretty excited to have an open "write once run everywhere" environment but the other part of me really likes that autoconf/cmake more or less provide that now and I'm worried that things like this will discourage people from making their projects easily buildable by the end user.
Docker already does that, try building freeciv-web yourself without tools like docker, the end result is that it can be very difficult to modify it when you need to.
What prevents me from writing a wasm file with an arbitrary value for "depth" greater than CALLSTACK_SIZE (1024) and overflowing the buffer? (If the answer is "nothing", that's probably arbitrary code execution.)