The following regular expression used to parse dates specified as strings is vulnerable to ReDoS:
/[0-9]*['a-z\u00A0-\u05FF\u0700-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]+|[\u0600-\u06FF\/]+(\s*?[\u0600-\u06FF]+){1,2}/i
The slowdown is moderately low: for 50.000 characters around 2 seconds matching time. However, I would still suggest one of the following:
If needed, I can provide an actual example showing the slowdown.
For clarification, this is in the matchWord
regex, in /src/lib/parse/regex.js
here.
Here is a railroad diagram of the regular expression. From this we can see that the grouping with repetition is related to parsing Arabic characters. It would be helpful if someone who understands both regular expressions and Arabic language could take a crack at this.
An overview of ReDoS is also helpful.
Ill take this is no one has already started
@hamiltondanielb all yours :)
@cristianstaicu
If needed, I can provide an actual example showing the slowdown.
I'd like to see a example if it's possible :)
@Drag0s sent it on your private email.
FYI, this was added to NSP (see here), so this is probably going to start breaking people's builds soon.
@hamiltondanielb - Did you get anywhere looking into this?
Just had our build break 👯
It's sad that the issue had to become public before it was fixed. Issue opened on Sep 8, NSP advisory published today. @cristianstaicu perhaps you should've reminded the maintainers about the disclosure deadline to give this some momentum.
@mattgrande there is a meta-ness to this: turns out the version of nsp we were pinned to (2.8.1) depends on moment (via joi) so it was reporting a vulnerability on its own dependency:
Upgrading to nsp 3.1.0, resolved this because the dependency is no longer there - so beware of that if you don't directly depend on moment.
Is there a fix for this yet?
Please advise any fix available?
No fix has been published yet.
Please, if you're interested in getting updates from the maintainers, subscribe to notifications for updates to this issue by clicking the "Subscribe" in the right-hand column.
To add an nsp
exception for this, add a .nsprc
file:
{
"exceptions": [
"https://nodesecurity.io/advisories/532"
]
}
Thanks @westy92 ! Saved my build.
Hi @westy92 and @jacob-go . I have the following code.
var tasksMethods = require('gulpfile-ninecms');
gulp.task('nsp', tasksMethods.nsp);
Its not picking up the .nsprc file exception. It keeps giving me the vulnerability error for moment.
I added the file on root of the project. Is there anything I am missing to do?
@Dexterslab we're using gulp-nsp
, which works fine when the .nsprc
is in the project directory (same level as package.json
). Maybe try using gulp-nsp
directly?
@cristianstaicu @mattgrande is this happening in Luxon as well?
We'd appreciate it the fix for this can be expedited, now that it has been logged in nsp it is failing our builds.
Can I suggest the maintainers to lock this convo?
For everyone waiting for a fix, just hit the subscribe button, and you’ll be notified.
If anyone want to undertake the fix, feel free to open a PR.
There is a PR for this already https://github.com/moment/moment/pull/4326
Does someone need to notify nsp
this has been patched? https://nodesecurity.io/advisories/532
This has been fixed in version 2.19.3 . Please update accordingly.
I'm not sure how to notify NSP -- @cristianstaicu could you or others help here?
I emailed [email protected]:
Hello,
The currently outstanding moment.js vulnerability (https://nodesecurity.io/advisories/532) was recently patched and the fix released in v.2.19.3.
What's the process for reporting status updates on advisories? This email address is the best avenue I could find.
Thanks!
Just got a reply that the NSP DB should be updated with 2.19.3 as the fixed version.
Verified on my end that 2.19.3 no longer alerts.
Most helpful comment
We'd appreciate it the fix for this can be expedited, now that it has been logged in nsp it is failing our builds.