search

meteor / meteor

Meteor, the JavaScript App Platform
https://meteor.com
Other
44.42k stars 5.2k forks source link

ReDoS in 3rd party module. #13341

Open zoli4c opened 2 months ago

zoli4c commented 2 months ago

The flaw is in useragent module here.

Meteor Framework always parse new User-Agent Header string by using useragent module, that could lead to Application HTTP Regex DoS following this issue.

The vulnerable code: https://github.com/meteor/meteor/blob/d3d191b8c4ba525ec178013d541c79f81e973de3/packages/webapp/webapp_server.js#L126

Recommend to limit length of User-Agent Header from user's request.

jankapunkt commented 2 months ago

Would the temporary solution, linked in the issue be sufficient in the meantime?

StorytellerCZ commented 2 months ago

Since that package is no longer maintained we should upgrade to something different. At least to this: https://github.com/schmod/useragent-ng

zoli4c commented 2 months ago

That's alright. I didn't test this package before, make sure that no longer lookup() or parse() user's input with no santized. Btw, any CVE assigned for this vulnerability?

StorytellerCZ commented 2 months ago

From my understanding the issue is even in one package up that has been fixed. Given that useragent is set to bring the latest version of that package it should not be an issue, but still I'll submit a PR to switch package just in case. The question is if anything else is needed afterwards or not. I'm happy to implement the workaround that was mentioned in the issue.

zoli4c commented 2 months ago

As I told you, I don't even know how the package useragent-ng or anyone was forked from useragent could against my ReDoS attack if your application keep parsing user's input via User-Agent header like that.

zoli4c commented 2 months ago

Just limit the length of User-Agent header before parse it. No need to another package, but anyway it's good when choosing the package under maintained.