Wac: Minimal WebAssembly interpreter written in C(github.com)
github.com
Wac: Minimal WebAssembly interpreter written in C
https://github.com/grassel/wac#wac---webassembly-in-c
43 comments
You should probably write this in an issue so that the developers see it.
It took me 10 minutes to find on my phone on the train. There are probably dozens of bugs like this...
Well, it is written in C...
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.
Want to use C? Fine.
But then actually use the myriad of compiler flags, static analysers and dependent typing tooling (Frama-C) available for it.
Some of them exist since 1979.
But then actually use the myriad of compiler flags, static analysers and dependent typing tooling (Frama-C) available for it.
Some of them exist since 1979.
“Unless someone like you cares a whole awful lot, nothing is going to get better. It's not.“ - dr. seuss
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.
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.
I bet it has a lot of bugs. Because it exists. Unlike a lot of “safe” Rust software ;)
Is it meant to be a sandbox? I don't see anything to that effect on the GitHub page.
When is Wasm not a sandbox?
Page one of the spec
– Safe: code is validated and executes in a memory-safe3, sandboxed environment preventing data cor-ruption or security breaches.
Page one of the spec
– Safe: code is validated and executes in a memory-safe3, sandboxed environment preventing data cor-ruption or security breaches.
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 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?
I nominate this thread for the Worst of HN. Reminds me of work.
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.
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.
Your rhetorical behavior is why I should leave HN. Trite, condescending, arrogant.
WASM is originally designed for the sandbox, but it doesn't mean that all its practical applications have to be sandboxed.
Wasm (not an acronym) assumes a sandbox, if an execution environment doesn't provide a sandbox it needs to clearly call that out.
This one clearly needs work in validating the Wasm sent to it.
This one clearly needs work in validating the Wasm sent to it.
Isn't it a combination of the first letter of Web and the common abbreviation for assembly language, ASM?
They're correct - it's an abbreviation (of Web assembly), but it's not an acronym, so "Wasm" is the proper casing.
link gives a 404 because the repo is renamed minutes ago to https://github.com/grassel/wac-esp
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.
[deleted]
not just a WASM interpreter, but one that is targeting small devices, which is pretty darned cool.
my thoughts go directly to fast over the air updates without a full flash, fixing bugs or reconfiguring on the fly.
my thoughts go directly to fast over the air updates without a full flash, fixing bugs or reconfiguring on the fly.
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.
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.
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.
Embedded programming will always be unsafe to a degree. You can't avoid interacting w/ hardware. Static analysis can only get you so far.
Hello World in Haskell would already be too large for many micro controllers.
[deleted]
For a interpreter targeted at small/embedded devices, it would be interesting to see the ROM/RAM usage.
Trial by fire: Get it on the PICO8: https://www.lexaloffle.com/pico-8.php
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.
meh, if you really want to try it on a game console at least pick one that resembles a computer/microcontroller.
The PICO8 is very pretty but it's not at all like small 8/16 bit computers.
The PICO8 is very pretty but it's not at all like small 8/16 bit computers.
The URL for the original project is [1]
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.
[1] https://github.com/kanaka/wac
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.
[1] https://github.com/kanaka/wac
Is the gcc team/clang team working to allow wasm as a target?
I heard there are several compilers that work with c++ but i don't see many.
I heard there are several compilers that work with c++ but i don't see many.
LLVM has a wasm target so, in theory, clang should be able yo target it without modifications .
In practice I found this short guide : https://stackoverflow.com/questions/45146099/how-do-i-compil...
This guide requires binaryen... I tried to build it once, it was not fun.
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.)