Stream: git-wasmtime

Topic: wasmtime / Issue #1874 Security of wasm module

Wasmtime GitHub notifications bot (Jun 12 2020 at 15:49):

donovano opened Issue #1874:

Hi, I’ve read the Webassembly security document at https://webassembly.org/docs/security/. I presume wasmtime is (mostly) alligned with the described security aspects in this document - except maybe some of the discussion about future features.

So is it correct that… after calling some wasm module function (from a host hosting the guest wasm), all wasm module code will be in a defined state i.e. that of a freshly initialized module, but the linear memory might be altered?

If one clears the linear memory space after the host calls the guest, can it then be said that the wasm module should be in an original state i.e. the state immediately after it was loaded but before any functions were executed? To put it another way: An attacker (maybe by passing crafty parameters to the wasm function) can have messed around with the memory and could have tried to execute functions but could not have altered anything else that persists after the function call exits except the memory, which can be cleared or reset by the caller (the host) upon completion of the function call?

Wasmtime GitHub notifications bot (Jun 12 2020 at 16:20):

bjorn3 commented on Issue #1874:

It could also have modified globals or tables, not just linear memory.

Wasmtime GitHub notifications bot (Jun 12 2020 at 17:54):

donovano commented on Issue #1874:

OK you're right those too. It seems the only way for the host to know about all globals and tables is to call the instance or module exports function and iterate over them. Not sure if you can save and restore these. I think you can save and restore a Global but not sure about a Table.

It would be nice if there was a restore capability that would do all this for you i.e. get the wasm module into its initial state after calling some wasm function(s).

Wasmtime GitHub notifications bot (Jun 12 2020 at 18:23):

yurydelendik commented on Issue #1874:

It would be nice if there was a restore capability that would do all this for you i.e. get the wasm module into its initial state after calling some wasm function(s).

I wonder how it will be different from just Instance::new. Notice that Module holds the code that can be (re)used in different instances.

Wasmtime GitHub notifications bot (Jun 12 2020 at 18:41):

donovano commented on Issue #1874:

OK. In my case after the call to Module::from_file(… there are some linker.func(… calls followed by a linker.instantiate(…. So I could maybe just create a new linker and call instantiate on this new linker with the module. Will have to see if it is necessary to ‘uninstantiate’ the old linker or remove it somehow.

Wasmtime GitHub notifications bot (Jun 12 2020 at 21:29):

donovano commented on Issue #1874:

This approach does work. I only have a problem with memory not being released. This is not a problem if the store and module are recreated after every function call, but if you keep the store and module and only create a new linker each time the memory increases steadily. I'll investigate further to get to the bottom unless you have some suggestions. Thanks for the help anyway.

Wasmtime GitHub notifications bot (Jun 12 2020 at 21:50):

yurydelendik commented on Issue #1874:

the store and module are recreated after every function call

A module does not need to be recreated (just cloned). Normally you will just create a Store and new Instance (in this Store), in your case you are using linker to assist with that.

Wasmtime GitHub notifications bot (Jun 12 2020 at 22:17):

yurydelendik commented on Issue #1874:

Please look at https://github.com/bytecodealliance/wasmtime/blob/master/examples/threads.rs -- it is looks like you use case (if threads are removed)

Wasmtime GitHub notifications bot (Jun 12 2020 at 22:17):

yurydelendik edited a comment on Issue #1874:

Please look at https://github.com/bytecodealliance/wasmtime/blob/master/examples/threads.rs -- it is looks like your use case (if threads are removed)

Wasmtime GitHub notifications bot (Jun 15 2020 at 13:42):

donovano commented on Issue #1874:

I was still on 0.16.0 so moving to 0.17.0 I got this to work thanks. This is a good approach except that CPU overhead caused by the processing to link functions and WASI each time is obviously much higher than doing that only once. Maybe this can improve over time or a different method can be used to re-initialize the module each time. But this is progress thanks.

Wasmtime GitHub notifications bot (Jun 15 2020 at 14:56):

yurydelendik commented on Issue #1874:

except that CPU overhead caused by the processing to link functions

The only overhead is memory re-creation, but I believe it can be re-used if wasm module imports it and the same storage (as memory) used during Instance::new. Other operations, such as looking up exports by string name, can be optimized by not using a linker at all.

@donovano is anything else needs to be addressed for this issue to be closed? IMHO I'm not sure it is a security issue at all.

Wasmtime GitHub notifications bot (Jun 15 2020 at 15:50):

donovano commented on Issue #1874:

OK can look at further optimizations. Thanks you can close it, this has helped.

I dont think it is a security problem or bug as such. I originally had a concern that one invocation of a wasm exported function can compromise the wasm guest to a limited degree (based on the good security protections that wasm offers) that might affect further calls to the exported functions. Re-initializing the module as described above each time prior to calling an exported function, specifically for a different initiator or user that calls this function, will mitigate this issue. So from security point of view I think it looks good.

Wasmtime GitHub notifications bot (Jun 15 2020 at 16:14):

yurydelendik closed Issue #1874:

Hi, I’ve read the Webassembly security document at https://webassembly.org/docs/security/. I presume wasmtime is (mostly) alligned with the described security aspects in this document - except maybe some of the discussion about future features.

So is it correct that… after calling some wasm module function (from a host hosting the guest wasm), all wasm module code will be in a defined state i.e. that of a freshly initialized module, but the linear memory might be altered?

If one clears the linear memory space after the host calls the guest, can it then be said that the wasm module should be in an original state i.e. the state immediately after it was loaded but before any functions were executed? To put it another way: An attacker (maybe by passing crafty parameters to the wasm function) can have messed around with the memory and could have tried to execute functions but could not have altered anything else that persists after the function call exits except the memory, which can be cleared or reset by the caller (the host) upon completion of the function call?

Last updated: Nov 22 2024 at 16:03 UTC