Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CWE-400 | Uncontrolled resource consumption #35

Closed
archanasharma3 opened this issue Mar 4, 2024 · 11 comments
Closed

CWE-400 | Uncontrolled resource consumption #35

archanasharma3 opened this issue Mar 4, 2024 · 11 comments

Comments

@archanasharma3
Copy link

Ran latest scan and landed with this issue - CWE-400 | Uncontrolled resource consumption

The NPM package "braces" fails to limit the number of characters it can handle, which could lead to Memory Exhaustion. In "lib/parse.js," if a malicious user sends "imbalanced braces" as input, the parsing will enter a loop, which will cause the program to start allocating heap memory without freeing it at any moment of the loop. Eventually, the JavaScript heap limit is reached, and the program will crash.

braces/lib/parse.js on line 308 - do {

@doowb
Copy link
Member

doowb commented Mar 12, 2024

@archanasharma3 could you provide the error you're seeing when the heap limit is reached and your program crashes?

The pattern length is checked here.
You could either check the pattern length before passing it to braces or handle the error in a try-catch.

There's also an option that will enforce a lower max length if you'd like to do that and catch the error.

@rahulmukherjee85
Copy link

In addition to @archanasharma3 comments,
braces flagged as vulnerable package:
Dependency npm:braces 3.0.2 is vulnerable
Cxab55612e-3a56 7.5 - CWE-400
Results powered by Checkmarx(c)
Braces is a transitive dependency of Npm-chokidar in our application.
there any way to set the limit in global level ? please let us know

@MarioTeixeiraCx
Copy link

Hello @doowb,

I'm reaching out here to confirm that this is indeed the other vulnerability reported by the Checkmarx CxResearch group. We opened this issue (micromatch/micromatch#243) after trying to reach out by email unsuccessfully. You can still find the details in the report we sent.

CVEs for both vulnerabilities will come out soon.

Thank you,
Mário Teixeira

@LoganArnett
Copy link

LoganArnett commented Apr 19, 2024

It looks like the description of this vulnerability is around the do/while loop for the imbalanced braces:

The NPM package "braces" fails to limit the number of characters it can handle, 
which could lead to Memory Exhaustion. In "lib/parse.js," if a malicious user sends 
"imbalanced braces" as input, the parsing will enter a loop, which will cause the 
program to start allocating heap memory without freeing it at any moment of the 
loop. Eventually, the JavaScript heap limit is reached, and the program will crash.

@MarioTeixeiraCx
Copy link

Hello @doowb ,

CVEs for micromatch and braces vulnerabilities are now public. You can see this comment for additional details:
micromatch/micromatch#243 (comment)

Best regards,
Mário Teixeira

@sdupont73
Copy link

Does anyone know when a fix is expected for this vulnerability?

@benjsmi
Copy link

benjsmi commented May 16, 2024

@sdupont73 -- I'm going to guess that the answer to "when is a fix coming" is probably never. The last commit to this repository was 2019. Same goes for the npm. I do not maintain this project, so I don't actually know, but we've not heard anything from the maintainers and there seems to be very little development effort, so my guess is that a replacement is a better option.

@BlueTux611
Copy link

For this issue proposed this as potential fix:

@prabhu
Copy link

prabhu commented May 21, 2024

So you found an infinite loop and then decided to call it a security vulnerability? The amount of time human civilization wastes with low quality CVEs is staggering.

@theta682
Copy link

I see a commit 9f5b4cf which is included in v3.0.3. Probably this means the issue is fixed.

@MarioTeixeiraCx
Copy link

Hi,

We did a PoC and can confirm that version 3.0.3 fixed the issue for CVE-2024-4068.

However, as stated here, the ReDoS vulnerability (CVE-2024-4067) still exists and can potentially be exploited if a certain library is calling the vulnerable method.

Best regards,
Mário Teixeira

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests