Re: [pcre-dev] PCRE_STUDY_JIT_COMPILE option bug?

Top Page

Reply to this message
Author: Ervin Hegedüs
To: pcre-dev
Subject: Re: [pcre-dev] PCRE_STUDY_JIT_COMPILE option bug?
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:

(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?

from this:

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:

with this rule:

The final pattern "builded" from the more "simple":

I just wrote these informations, that we don't know, how long
can be an expression - most of them are changing and grow

Thanks again,