You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a meta-issue for a big goal: be sure that malicious code in WRAPP can get out of Webrogue during execution (weather with AOT or without). Known attack vectors are:
Vulkan. It's kinda unsafe by design, and isolating it using virglrenderer's jailed worker is not an option. Should Vulkan be flagged as non-sandboxable?
WASIp1. Safe by design, but its implementation is unmaintained. Related to WASIp3 support #46
Rust dependencies. Forked Wasmtime is the most likely attack vector, and gets CVEs sometimes, so it should be updated frequently. Dependencies from crates.io are managed by dependabot, but PR's are approved manually and not frequently. Webrogue also depends on LLVM's LLD, but I can't imagine how to exploit it
Path traversal. VFS implementation may be vulnerable to this kind of attack. I added some checks, but not tested them.
Unsafe code. Webrogue codebase contains lots of unsafe { } without any explanation.
Skill issue. I'm not a cybersecurity specialist and can't prove that something is safe.
This is a meta-issue for a big goal: be sure that malicious code in WRAPP can get out of Webrogue during execution (weather with AOT or without). Known attack vectors are:
unsafe { }without any explanation.