Known security issues

[robotlolita]

This is a meta-issue to keep track of the security issues that are currently known, but not deemed immediate enough to fix during the experimental Crochet phase. That doesn't mean these security issues aren't dangerous, though. And they do certainly pose a threat to pretty much all security guarantees Crochet can provide.

• Node wrapper libraries don't use effects --- this makes it hard to provide safe experimentation with them.
• No IR validation --- this means attackers are able to craft IR binaries where define operations can execute arbitrary code. What this means is that attacks abusing capabilities can take place at load time rather than run time. The launcher currently assumes loading a package is safe, making opening packages dangerous.
• Non-audited dependencies --- the dependencies that make up Crochet's VM and tools have not been audited. It's possible that they contain undesirable code and capabilities.
• Non-verified JS compiler --- Browser packages are generated with Browserify, which includes its own runtime and isn't a verified compiler. It's possible that Browserify introduces bugs that weren't present in the original source code.
• Trusted FFI provided to non-TCB packages --- The trusted FFI would allow attackers to modify the VM semantics, and interact with the VM in unsupported ways. That said, native code isn't sandboxed at all to begin with, so there are bigger problems there.
• Some TCB dependencies are not audited --- And we rely on package managers to install them. This makes the VM, runtime, and tools vulnerable to dependency hijacking.
• Typed data supports dynamic projections --- If a piece of code uses X.[K] for their own internal typed structure, and K is provided by an attacker, they would be able to bypass projection capabilities and extract private data.
• No provenance checks on packages --- Crochet relies on package names being unique and readily identifiable (traceable to a source), however there's nothing that enforces this today. As a result attackers can abuse this by setting the name of their package to anything and trick users into granting them capabilities.
• Assets can be accessed by other packages --- Currently the URI for assets on the web includes no capabilities, so any package with the ability of making network requests can access other package's assets.
• Sensitive data may be leaked with debug representations --- As long as Crochet's debugging tools are in this transitionary state from rudimentary JS pretty-printing to capability-aware representations in Crochet code, the JS pretty-printing part will leak possibly boxed/secret data to standard output and other debugging outputs.
• Paths generated without semantic guarantees --- The assets code currently generates some paths without semantic guarantees about their composition. There might be cases where this results in paths that are unexpected. Also file systems are a mess so there's a lot else here that needs attention.