Closed adammcclenaghan closed 7 months ago
Removed the possessive quantifiers because they're not supported in golang
Runtime still fixed with this new regex
Pumps | Match Runtime (ns) |
---|---|
0 | 226687 |
1 | 17758 |
2 | 17034 |
3 | 21194 |
4 | 21196 |
5 | 23365 |
6 | 41325 |
7 | 28272 |
8 | 32467 |
9 | 55776 |
10 | 59842 |
11 | 59216 |
12 | 58549 |
13 | 64604 |
14 | 34011 |
15 | 80653 |
16 | 120135 |
Can't run verify hooks locally as ruby won't play nice with my system and I don't have enough time today to fix it.
I did test the new pattern locally against a bunch of patterns. If anything the original regex seems likely too permissive as it matches the likes of PolycomRealPresenceGroup123/__..1.2.3
but since I couldn't find any real banner examples from a quick look online I tried not to change the behaviour of which inputs we match with this change.
Description
The Regex changed suffers from an exponential degree of ambiguity.
As a result it is trivial to provide an input string which takes an incredibly long time to match (due to exponential growth by length of input string).
Related: https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS
Here's an example of how to show this with code.
Tested on Java 8 which exhibits the issue. Tested on Java 11 which did not present the issue, some research online suggests that Java 11 featured some improvements to try to mitigate this. Either way, since this is a collection of patterns which are language agnostic we should probably not support patterns like this.
Motivation and Context
I ran this library against all of the patterns within Recog, only one showed an exponential degree of ambiguity so I am fixing it.
How Has This Been Tested?
Functional: Tested with java code shown above to prove out that the new regex does not exhibit this issue.
Regression: The existing example test case for this regex passes
Types of changes
Checklist: