Deno, a JavaScript runtime, markets itself as 'Secure by Default' by requiring explicit permissions for code to access the outside world. However, a technical critique argues that this model is fundamentally insecure because it emulates system-level security by filtering standard library calls rather than isolating the process at the operating system level.
This image provides a visual reference to the specific code-level analysis used to critique Deno's security model.
This image complements the first by showing further technical details of the security critique.
The Vulnerability of Terminal Prompts
Deno's permission system displays interactive prompts in the terminal to ask users for permission at runtime. Because these prompts are sent as plain text to stdout and receive input from stdin, they share the same communication channel as the potentially malicious code being executed.
An attacker can manipulate terminal colors or use non-standard escape codes to hide or spoof these prompts. This creates a situation where a user might unknowingly provide approval to a request because the terminal state was altered by the code before the prompt appeared.
“Deno process is not actually sandboxed, it only pretends it is.”
— I’m not a fan of Deno’s security model | max’s place
Escaping the Sandbox via Environment Variables
The '--allow-run' flag is intended to let a program execute a specific command, such as 'uname'. However, because programs are identified by names rather than unique paths, an attacker can modify the PATH environment variable to point to a malicious binary with the same name.
Furthermore, even if the PATH is secured, most executables use a dynamic loader that can be influenced by environment variables like LD_PRELOAD. By injecting a malicious library into the loading process, an attacker can execute arbitrary code on load, effectively bypassing Deno's permission checks.
Pseudo-Sandboxing vs. True Isolation
The core issue identified is that Deno is not a true sandbox; it is a runtime that filters its own standard library APIs. This approach breaks down the moment a program interacts with the operating system through means outside of Deno's specific library.
While Deno's model may protect against 'unsmart' malicious code, it provides a false sense of security for high-risk untrusted execution. The author concludes that the only robust solution is to use a proper OS-level sandbox to isolate the process entirely, rather than trying to manage a list of allowed standard library calls.