Hi Philip,
On Sat, Jan 26, 2019 at 04:26:45PM +0000, ph10@??? wrote:
> On Sat, 26 Jan 2019, Ervin Hegedüs via Pcre-dev wrote:
>
> > I don't know inside of PCRE, and the used API (I just fond a
> > "bug" on of my project), so I think I have to see, what does it
> > mean the ovector. The application can use longest pattern, than
> > this... so I guess the 40 isn't the solution for "all cases".
> >
> > Is there any best practice to calculate the size? What other
> > consequence is there, when I increase that size? Eg. more memory
> > using, slower runtime...?
>
> In PCRE2 there *is* a way of dealing with this. Instead of providing a
> separate ovector, the application calls a function to create a "match
> block" that contains the ovector, and one way of specifying how big the
> ovector should be is "as big as necessary for this pattern".
well, may be that'll be problem - now I realised that you wrote
that the API is changed, but the library we used (I guess) the old:
https://github.com/SpiderLabs/ModSecurity/blob/dc78c0e180d09aa1b2f0ffad1a8d6967e69f984f/src/utils/regex.cc#L46
(also see the line 31., where the macro exists).
> More memory, yes, but probably insignificant effect on runtime.
that's no problem - the library's size is over 60MB now... :)
(The project is the ModSecurity3)
> > The "for some reason" is a little bit disquieting :), you mean
> > that this result is not deterministic?
>
> I suspect it's a bug/oversight in the old PCRE1 code, but as I said in
> my previous message, I'm not inclined to investigate further.
ok, so what do you think? Should we align the library to new API?
https://www.pcre.org/current/doc/html/
from this:
https://www.pcre.org/original/doc/html/
and our problem solved?
Is there any other way that we keep the current one? Eg. as Zoli
said icrease the size of OVECTOR? If it is a solution, how should
we increase the size?
(Note: I've ran into this problem when I started to check the
OWASP CRS (Core Rule Set) with new ModSec with several HTTPD's.
There is a good testing framework, and one of those checks the
SQL injection:
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.2/dev/util/regression-tests/tests/REQUEST-942-APPLICATION-ATTACK-SQLI/942130.yaml
with this rule:
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/4ad894096c4100a8a3813b24cd47d51ac8d50cbd/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf#L570
The final pattern "builded" from the more "simple":
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.2/dev/util/regexp-assemble/regexp-942130.data
I just wrote these informations, that we don't know, how long
can be an expression - most of them are changing and grow
fat...)
Thanks again,
a.
