Deno is a JavaScript, TypeScript, and WebAssembly runtime. Prior to versions 2.1.13 and 2.2.13, the `Deno.env.toObject` method ignores any variables listed in the `--deny-env` option of the `deno run` command. When looking at the documentation of the `--deny-env` option this might lead to a false impression that variables listed in the option are impossible to read. Software relying on the combination of both flags to allow access to most environment variables except a few sensitive ones will be vulnerable to malicious code trying to steal secrets using the `Deno.env.toObject()` method. Versions 2.1.13 and 2.2.13 contains a patch.
Deno is a JavaScript, TypeScript, and WebAssembly runtime. Starting in version 2.2.0 and prior to versions 2.2.5, it is possible to bypass Deno's permission read/write db permission check by using `ATTACH DATABASE` statement. Version 2.2.5 contains a patch for the issue.
Deno is a JavaScript, TypeScript, and WebAssembly runtime. Starting in version 1.41.3 and prior to versions 2.1.13, 2.2.13, and 2.3.2, `deno run --allow-read --deny-read main.ts` results in allowed, even though 'deny' should be stronger. The result is the same with all global unary permissions given as `--allow-* --deny-*`. This only affects a nonsensical combination of flags, so there shouldn't be a real impact on the userbase. Users may upgrade to version 2.1.13, 2.2.13, or 2.3.2 to receive a patch.
Deno is a JavaScript, TypeScript, and WebAssembly runtime. Versions 1.46.0 through 2.1.6 have an issue that affects AES-256-GCM and AES-128-GCM in Deno in which the authentication tag is not being validated. This means tampered ciphertexts or incorrect keys might not be detected, which breaks the guarantees expected from AES-GCM. Older versions of Deno correctly threw errors in such cases, as does Node.js. Without authentication tag verification, AES-GCM degrades to essentially CTR mode, removing integrity protection. Authenticated data set with set_aad is also affected, as it is incorporated into the GCM hash (ghash) but this too is not validated, rendering AAD checks ineffective. Version 2.1.7 includes a patch that addresses this issue.
An issue in `.npmrc` support in Deno 1.44.0 was discovered where Deno would send `.npmrc` credentials for the scope to the tarball URL when the registry provided URLs for a tarball on a different domain. All users relying on .npmrc are potentially affected by this vulnerability if their private registry references tarball URLs at a different domain. This includes usage of deno install subcommand, auto-install for npm: specifiers and LSP usage. It is recommended to upgrade to Deno 1.44.1 and if your private registry ever serves tarballs at a different domain to rotate your registry credentials.
Deno is a JavaScript, TypeScript, and WebAssembly runtime with secure defaults. The Deno sandbox may be unexpectedly weakened by allowing file read/write access to privileged files in various locations on Unix and Windows platforms. For example, reading `/proc/self/environ` may provide access equivalent to `--allow-env`, and writing `/proc/self/mem` may provide access equivalent to `--allow-all`. Users who grant read and write access to the entire filesystem may not realize that these access to these files may have additional, unintended consequences. The documentation did not reflect that this practice should be undertaken to increase the strength of the security sandbox. Users who run code with `--allow-read` or `--allow-write` may unexpectedly end up granting additional permissions via file-system operations. Deno 1.43 and above require explicit `--allow-all` access to read or write `/etc`, `/dev` on unix platform (as well as `/proc` and `/sys` on linux platforms), and any path starting with `\\` on Windows.
Deno is a JavaScript, TypeScript, and WebAssembly runtime with secure defaults. By using ANSI escape sequences and a race between `libc::tcflush(0, libc::TCIFLUSH)` and reading standard input, it's possible to manipulate the permission prompt and force it to allow an unsafe action regardless of the user input. Some ANSI escape sequences act as a info request to the master terminal emulator and the terminal emulator sends back the reply in the PTY channel. standard streams also use this channel to send and get data. For example the `\033[6n` sequence requests the current cursor position. These sequences allow us to append data to the standard input of Deno. This vulnerability allows an attacker to bypass Deno permission policy. This vulnerability is fixed in 1.42.2.
Deno is a JavaScript, TypeScript, and WebAssembly runtime. In version 1.39.0, use of raw file descriptors in `op_node_ipc_pipe()` leads to premature close of arbitrary file descriptors, allowing standard input to be re-opened as a different resource resulting in permission prompt bypass. Node child_process IPC relies on the JS side to pass the raw IPC file descriptor to `op_node_ipc_pipe()`, which returns a `IpcJsonStreamResource` ID associated with the file descriptor. On closing the resource, the raw file descriptor is closed together.
Use of raw file descriptors in `op_node_ipc_pipe()` leads to premature close of arbitrary file descriptors. This allow standard input (fd 0) to be closed and re-opened for a different resource, which allows a silent permission prompt bypass. This is exploitable by an attacker controlling the code executed inside a Deno runtime to obtain arbitrary code execution on the host machine regardless of permissions.
This bug is known to be exploitable. There is a working exploit that achieves arbitrary code execution by bypassing prompts from zero permissions, additionally abusing the fact that Cache API lacks filesystem permission checks. The attack can be conducted silently as stderr can also be closed, suppressing all prompt outputs.
Version 1.39.1 fixes the bug.
Deno is a JavaScript, TypeScript, and WebAssembly runtime. Starting in version 1.36.2 and prior to version 1.40.3, use of inherently unsafe `*const c_void` and `ExternalPointer` leads to use-after-free access of the underlying structure, resulting in arbitrary code execution. Use of inherently unsafe `*const c_void` and `ExternalPointer` leads to use-after-free access of the underlying structure, which is exploitable by an attacker controlling the code executed inside a Deno runtime to obtain arbitrary code execution on the host machine regardless of permissions. This bug is known to be exploitable for both `*const c_void` and `ExternalPointer` implementations. Version 1.40.3 fixes this issue.
Deno is a JavaScript, TypeScript, and WebAssembly runtime. Starting in version 1.35.1 and prior to version 1.36.3, a vulnerability in Deno's Node.js compatibility runtime allows for cross-session data contamination during simultaneous asynchronous reads from Node.js streams sourced from sockets or files. The issue arises from the re-use of a global buffer (BUF) in stream_wrap.ts used as a performance optimization to limit allocations during these asynchronous read operations. This can lead to data intended for one session being received by another session, potentially resulting in data corruption and unexpected behavior. This affects all users of Deno that use the node.js compatibility layer for network communication or other streams, including packages that may require node.js libraries indirectly. Version 1.36.3 contains a patch for this issue.