Version: master branch
Subsystem: readline
lib/readline.js contains this code snippet:
Interface.prototype._wordLeft = function() {
if (this.cursor > 0) {
var leading = this.line.slice(0, this.cursor);
var match = leading.match(/(?:[^\w\s]+|\w+|)\s*$/);
this._moveCursor(-match[0].length);
}
};
This regex is quadratic: /(?:[^\w\s]+|\w+|)\s*$/.
I would be shocked if this were a viable ReDoS vector (hence the public bug report), but if this.line can be long (100K chars?) then it might present a performance problem.
I have not investigated reachability/triggerability nor the use cases of readline.
It is very unlikely that this.line would exceed even 100 characters. But it is theoretically possible. I do not worry about the performance in this case due to the average short input per line.
I don't think it's a massive problem if a copy-paste takes a second to parse or something
If its just our REPL, its hard to see this as an issue.
If readline is attached over TLS to a remote user, and used to implement some remote protocol, would we care then?
Also, what would it take to fix this?
@nodejs/security @nodejs/security-wg
At one point, @mscdex left the following comment:
FWIW it's important to remember that readline can be used outside of a repl context....
I'm not sure why it was deleted, but any use of readline outside of the REPL (or similar) could be an issue.
To clarify, this function is only called in response to key presses.
Also, what would it take to fix this?
Manually unrolling the regexp should work, I think.
Seems like a fix was landed in https://github.com/nodejs/node/commit/e4e2b0ce134ce781847272ae0b4bb889e75f223f
Most helpful comment
It is very unlikely that
this.linewould exceed even 100 characters. But it is theoretically possible. I do not worry about the performance in this case due to the average short input per line.