23 ms·

Given the amount of C++ in this project, I wouldn't run this in an adversarial environment. Meaning, I would not accept untrusted Wasm modules. It is about 100k

Given the amount of C++ in this project, I wouldn't run this in an adversarial environment. Meaning, I would not accept untrusted Wasm modules. It is about 100kloc of C/C++ including headers.

frutiger 4y ago
I would sincerely be curious to know how many “kloc of C/C++” you are already running in an adversarial environment and how much of a dent this project would make.
- nerpderp82 4y ago
  How much of a dent (non-quantitative) it would make, depends on how it is deployed. In my environment, the risk of WasmEdge outweighs its advantages. By that argument there is no difference between 80% and 85% or 1% and 2%. One should absolutely reduce their attack surface. If the goal is to be "lightweight" as compared to containers, then WasmEdge would be running as a regular OS process and not in a jail or cgroups container. By construction, WasmEdge has a greater threat model vs rootless containers. I am huge fan of Wasm, but my appreciation for a technology doesn't outweigh the risk posed by the runtime. Its security properties are intractable. Are you saying that end users should overlook this?
  - frutiger 4y ago
    > By construction, WasmEdge has a greater threat model vs rootless containers. Yes — this argument makes a lot more sense to me compared to “kloc of C/C++”.
juntao 4y ago
I am a maintainer of the WasmEdge project. Yes, it is written in C++ for two reasons: 1 C++ apps can run a lot of edge hardware devices and OSes. We are running on RTOS like seL4 and CPUs like RISC-V. 2 There are already two leading Wasm runtimes written in Rust when we started. We thought runtime diversity is important from security and reliability point of view. It is indeed more challenging to run C++ programs securely. We are participating Google’s OSS-fuzz program. Of course, for application developers, WasmEdge provides “Rust first” SDKs and APIs. Almost all of our new features are available in the Rust SDK first. :)
- nerpderp82 4y ago
  Besides fuzzing, what other security measures does WasmEdge use? Is it able to use memory protection on platforms where it is available?
jeffparsons 4y ago
C++ _can_ be written safely, as long as the right static and dynamic analysers are used. So while I wouldn't recommend it for _many_ new projects these days, the WasmEdge authors have good reasons to choose C++ and appear to be using it responsibly. Also, there are so many things that need to be done right for a VM specifically to actually be safe that merely being written in a safer language is lightyears away from being adequate. You _still_ need very careful design, dynamic analysers, and a whole lot of fuzzing if you want to end up with something you can reasonably trust. So if it were written in Rust as Wasmtime is, that alone wouldn't actually give me much more confidence that it's safe to use it on untrusted inputs. I say all this as a huge advocate for Rust in general. Sometimes the less attractive tool is actually a better choice.
- nerpderp82 4y ago
  This response is a mess, I apologize. One can do lots of things. Yes all of those things are still issues, but in enumerating all the things as you have, you make a compelling argument not to use C++. If one picks something else like SML, Go or even Rust, it allows them to focus on those common areas of correctness and not also, all that other stuff. I don't think you are apologizing for C++, but I hear this a lot, whatabout all the other parts that are fixed by a more sound system? My response is that we only have so many decisions we can make in the day, using a system that removes whole classes of problems allows me to focus on the non-accidental (forced) complexity. > Rust as Wasmtime is, that alone wouldn't actually give me much more confidence that it's safe I never made that argument. But let's say I did. Given two systems, one made in Rust and one made in C++. How do I audit the C++ code to ensure that it has the same level of safety as basically _anything_ else? WasmEdge is using code coverage, good! https://app.codecov.io/gh/WasmEdge/WasmEdge https://app.codecov.io/gh/WasmEdge/WasmEdge Only 80% coverage, not great. I see mention of fuzzing being used, but I only get 69 hits in the codebase for "fuzz" and no documentation about how it actually works. Wasmtime includes documentation on how to use their fuzzer, https://github.com/bytecodealliance/wasmtime/tree/main/fuzz https://github.com/bytecodealliance/wasmtime/tree/main/fuzz In my cursory look at the WasmEdge codebase I see No application UBSan [1] No application of control flow guard [2], either in the build or in the generated LLVM output. Infact the only sanitization flags they are passing are -fsanitize=fuzzer,address 0 mentions of 'control flow' in the WasmEdge codebase, 65 mentions in Wasmtime. Although it doesn't appear that Wasmtime is itself being compiled with cfguard. 309 mention of spectre mitigations in Wasmtime, 1 link to a cloudflare blogpost in WasmEdge. In my cursor look at Wasmtime, I see Much better fuzzing support, 85 uses of unsafe in cranelift itself, 1400+ uses of unsafe in crates/* The changelog and git messages for WasmEdge talk about type errors (those type errors look impossible in Rust), bus errors, out of bounds, etc. It does not inspire confidence. C++ is already starting from behind. This software is targeted to be run on bare metal, embedded and widely distributed. It just doesn't have the level of detail around testing and correctness that I would expect for such a critical piece of infrastructure. I am not saying that Wasmtime does not also have issues, that would be preposterous. But on the face of it, WasmEdge has a lot of work to do to catch up to where Wasmtime already is. Wasmtime appears to care about the security properties of their dependencies with https://mozilla.github.io/cargo-vet/ https://mozilla.github.io/cargo-vet/ It does not look like the WasmEdge project applies this basic list of practices as outlined by Jason Turner [n] [1] https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html [2] https://www.zdnet.com/article/microsofts-control-flow-guard-comes-to-rust-and-llvm-compilers/ https://www.zdnet.com/article/microsofts-control-flow-guard-... https://clang.llvm.org/docs/ControlFlowIntegrity.html https://clang.llvm.org/docs/ControlFlowIntegrity.html [n] https://www.youtube.com/watch?v=q7Gv4J3FyYE https://www.youtube.com/watch?v=q7Gv4J3FyYE https://github.com/lefticus/cpp_weekly/issues/175 https://github.com/lefticus/cpp_weekly/issues/175

Given the amount of C++ in this project, I wouldn't run this in an adversarial environment. Meaning, I would not accept untrusted Wasm modules. It is about 100kloc of C/C++ including headers.

frutiger 4y ago

I would sincerely be curious to know how many “kloc of C/C++” you are already running in an adversarial environment and how much of a dent this project would make.

nerpderp82 4y ago
How much of a dent (non-quantitative) it would make, depends on how it is deployed. In my environment, the risk of WasmEdge outweighs its advantages. By that argument there is no difference between 80% and 85% or 1% and 2%. One should absolutely reduce their attack surface. If the goal is to be "lightweight" as compared to containers, then WasmEdge would be running as a regular OS process and not in a jail or cgroups container. By construction, WasmEdge has a greater threat model vs rootless containers. I am huge fan of Wasm, but my appreciation for a technology doesn't outweigh the risk posed by the runtime. Its security properties are intractable. Are you saying that end users should overlook this?
- frutiger 4y ago
  > By construction, WasmEdge has a greater threat model vs rootless containers. Yes — this argument makes a lot more sense to me compared to “kloc of C/C++”.

juntao 4y ago

I am a maintainer of the WasmEdge project. Yes, it is written in C++ for two reasons: 1 C++ apps can run a lot of edge hardware devices and OSes. We are running on RTOS like seL4 and CPUs like RISC-V. 2 There are already two leading Wasm runtimes written in Rust when we started. We thought runtime diversity is important from security and reliability point of view. It is indeed more challenging to run C++ programs securely. We are participating Google’s OSS-fuzz program. Of course, for application developers, WasmEdge provides “Rust first” SDKs and APIs. Almost all of our new features are available in the Rust SDK first. :)

nerpderp82 4y ago
Besides fuzzing, what other security measures does WasmEdge use? Is it able to use memory protection on platforms where it is available?

jeffparsons 4y ago

C++ _can_ be written safely, as long as the right static and dynamic analysers are used. So while I wouldn't recommend it for _many_ new projects these days, the WasmEdge authors have good reasons to choose C++ and appear to be using it responsibly. Also, there are so many things that need to be done right for a VM specifically to actually be safe that merely being written in a safer language is lightyears away from being adequate. You _still_ need very careful design, dynamic analysers, and a whole lot of fuzzing if you want to end up with something you can reasonably trust. So if it were written in Rust as Wasmtime is, that alone wouldn't actually give me much more confidence that it's safe to use it on untrusted inputs. I say all this as a huge advocate for Rust in general. Sometimes the less attractive tool is actually a better choice.

nerpderp82 4y ago
This response is a mess, I apologize. One can do lots of things. Yes all of those things are still issues, but in enumerating all the things as you have, you make a compelling argument not to use C++. If one picks something else like SML, Go or even Rust, it allows them to focus on those common areas of correctness and not also, all that other stuff. I don't think you are apologizing for C++, but I hear this a lot, whatabout all the other parts that are fixed by a more sound system? My response is that we only have so many decisions we can make in the day, using a system that removes whole classes of problems allows me to focus on the non-accidental (forced) complexity. > Rust as Wasmtime is, that alone wouldn't actually give me much more confidence that it's safe I never made that argument. But let's say I did. Given two systems, one made in Rust and one made in C++. How do I audit the C++ code to ensure that it has the same level of safety as basically _anything_ else? WasmEdge is using code coverage, good! https://app.codecov.io/gh/WasmEdge/WasmEdge https://app.codecov.io/gh/WasmEdge/WasmEdge Only 80% coverage, not great. I see mention of fuzzing being used, but I only get 69 hits in the codebase for "fuzz" and no documentation about how it actually works. Wasmtime includes documentation on how to use their fuzzer, https://github.com/bytecodealliance/wasmtime/tree/main/fuzz https://github.com/bytecodealliance/wasmtime/tree/main/fuzz In my cursory look at the WasmEdge codebase I see No application UBSan [1] No application of control flow guard [2], either in the build or in the generated LLVM output. Infact the only sanitization flags they are passing are -fsanitize=fuzzer,address 0 mentions of 'control flow' in the WasmEdge codebase, 65 mentions in Wasmtime. Although it doesn't appear that Wasmtime is itself being compiled with cfguard. 309 mention of spectre mitigations in Wasmtime, 1 link to a cloudflare blogpost in WasmEdge. In my cursor look at Wasmtime, I see Much better fuzzing support, 85 uses of unsafe in cranelift itself, 1400+ uses of unsafe in crates/* The changelog and git messages for WasmEdge talk about type errors (those type errors look impossible in Rust), bus errors, out of bounds, etc. It does not inspire confidence. C++ is already starting from behind. This software is targeted to be run on bare metal, embedded and widely distributed. It just doesn't have the level of detail around testing and correctness that I would expect for such a critical piece of infrastructure. I am not saying that Wasmtime does not also have issues, that would be preposterous. But on the face of it, WasmEdge has a lot of work to do to catch up to where Wasmtime already is. Wasmtime appears to care about the security properties of their dependencies with https://mozilla.github.io/cargo-vet/ https://mozilla.github.io/cargo-vet/ It does not look like the WasmEdge project applies this basic list of practices as outlined by Jason Turner [n] [1] https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html [2] https://www.zdnet.com/article/microsofts-control-flow-guard-comes-to-rust-and-llvm-compilers/ https://www.zdnet.com/article/microsofts-control-flow-guard-... https://clang.llvm.org/docs/ControlFlowIntegrity.html https://clang.llvm.org/docs/ControlFlowIntegrity.html [n] https://www.youtube.com/watch?v=q7Gv4J3FyYE https://www.youtube.com/watch?v=q7Gv4J3FyYE https://github.com/lefticus/cpp_weekly/issues/175 https://github.com/lefticus/cpp_weekly/issues/175