Skip to content

Security-oriented sandboxing #114

Description

@Destructor17

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions