The Wayback Machine - https://web.archive.org/web/20211003213910/https://github.com/github/codeql/pull/6734
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

JS/PY: do not filter away regular expressions with lookbehinds #6734

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

@erik-krogh
Copy link
Contributor

@erik-krogh erik-krogh commented Sep 22, 2021

The new result in the tests appears to be a TP (although I'm not sure, it appears to be an invalid RegExp according to V8).

CVE-2021-3795: TP/TN

The original PR that filtered away lookbehinds was the PR that added support for lookbehinds throughout the JavaScript analysis. But no new tests for ReDoS were added back then, so I'm not sure what the motivation was.

I can't think of a realistic way of causing an FP with this change.

Python evaluation looks OK.
JavaScript evaluation looks OK.

@erik-krogh erik-krogh changed the title JS: do not filter away regular expressions with lookbehinds JS/PY: do not filter away regular expressions with lookbehinds Sep 22, 2021
@erik-krogh erik-krogh marked this pull request as ready for review Sep 22, 2021
@erik-krogh erik-krogh requested review from as code owners Sep 22, 2021
asgerf
asgerf approved these changes Sep 23, 2021
Copy link
Contributor

@asgerf asgerf left a comment

We still don't include lookbehinds in the NFA construction, so a lookbehind will be seen as a rejection (a state with no outgoing transitions), and if it occurs after the pump this could lead to a spurious rejecting suffix being found.

If we wanted to play it safe I'd say we'd need to add a transition which acts as epsilon during rejecting-suffix construction, and as an unmatchable symbol during the pump.

But like you said, it's hard to think of a realistic scenario where this would happen, so I'm ok with leaving it like this for now.

Maybe add a change note?

@erik-krogh
Copy link
Contributor Author

@erik-krogh erik-krogh commented Sep 24, 2021

Maybe add a change note?

I don't think this needs a change note.

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

Successfully merging this pull request may close these issues.

None yet

2 participants