Abdullah AlHamdan (CISPA Helmholtz Center for Information Security), Cristian-Alexandru Staicu (CISPA Helmholtz Center for Information Security)
Node.js and its ecosystem npm are notoriously insecure, enabling the proliferation of supply chain attacks. Deno is an emerging runtime that promises to offer a safer alternative for running untrusted JavaScript code outside of the browser. Learning from Node.js’s mistakes, Deno is written in Rust, a memory-safe programming language, and it includes a strict permission system that checks all accesses to sensitive APIs via static or runtime permissions. Deno also allows the inclusion of third-party code via URLs, which promises a more transparent way of handling dependencies, advocating for a fully decentralized software supply chain. In this paper, we study if Deno delivers on its promise of increased security. We find that indeed Deno has a smaller attack surface than Node.js, but there still are known attacks that are not addressed (ReDoS) or only partially mitigated (prototype pollution). Moreover, we find several weaknesses in Deno’s permission system, which allow sophisticated supply chain attacks. First, coarse-grained permissions allow attackers to abuse the ambient authority of the operating system to sidestep the permission system. Second, we find that URL imports are exempted from the permission checks, allowing attackers to perform unlawful network requests. We also identify time-of-check to time-of-use issues when handling symbolic links, making fine-grained file system access control ineffective. We then perform an empirical study of Deno’s main ecosystem deno.land to understand how developers consume third-party code and how permissions are used and communicated. We identify classical URL-related issues such as expired domains and reliance on insecure transport protocols, but we also find that it is challenging to guarantee uniform immutability and version control when multiple domains are involved in code distribution. We also provide initial evidence that developers poorly document required permissions on deno.land and that they tend to abuse coarse-grained permissions, reducing the benefits of the permission system. Our findings resulted in two security advisories for Deno and a redesign of its import mechanism. We also make concrete recommendations for improving Deno’s security model to further prevent supply chain attacks: add import permissions, additional access control at file system level, support for compartmentalization, and a manifest file that persists fine-grained permissions.