https://bytecodealliance.org/articles/xz-backdoor-and-wasmtime
Curious about this wrt wasm: IIUC the malware was hidden quite deeply in a test binary ... As #warg and other binary distributions become more common, and the vision of being able to hot swap components inside a composed wasm system very easily becomes realized, what will be the safeguards in place to avoid XZ like issues with them?
I could imagine as the blog posed in this topic states that module isolation can help. But with wasi fs capable modules most of all, I could see this still happening:
Is it fair to say that there is not explicit hierarchy of components as well? Meaning anywhere in composition a module could import wasi and thus at least request system resources that might be exploited... Right? (Meaning that injection of something malicious could happen in any module)
Is there means to be alerted and/or restricted access per module for auditing wasm bnary packages now? (I bet there could be if wit compliance within the binary is enforced for components with any wasi imports if not yet - it would be at least possible to monitor changes in the wasi imports... But not sure how you could assure no malicous changes in runtime behavior really)
A (non-root) component cannot get an import directly from the host; it can only receive it from the component that instantiates it. If a composition doesn't provide a wasi instance to some subtree of components there is no way for any component in that subtree to "reach out" and get access to that functionality.
Is it fair to say that there is not explicit hierarchy of components as well?
Nope! :smile:
@Luke Wagner's talk on components might of interest to you: YouTube - Keynote: What is a Component (and Why)? - Luke Wagner, Distinguished Engineer, Fastly
Last updated: Dec 23 2024 at 13:07 UTC