https://bugs.exim.org/show_bug.cgi?id=2765
Giuseppe D'Angelo <dangelog@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dangelog@???
--- Comment #4 from Giuseppe D'Angelo <dangelog@???> ---
Couple of considerations.
The first is whether this is actually exposing a bug in pcre_dfa_exec (using
pcretest to demonstrate it), or "merely" a bug in pcretest. Given the input is
clearly coming out of a fuzzing test, I can't discern it easily, so it's hard
for me to say. Having a minimal C example for this sort of things would be much
better.
(Having said that, the code in pcretest looks "innocent" enough at a quick
glance, so maybe this is really about pcre_dfa_exec passing wrong offsets to
the callout, causing a out of bounds read by pcretest's callout callback.)
This issue is security-related only if it involves pcre_dfa_exec; if it's a
pcretest-only bug, then it's not. pcretest is not supposed to be used to run
untrusted inputs. It's a testing facility for PCRE itself, and a quick helper
to try regexps out (if you don't like running perl, or going to regex101,
etc.), but it's by no means an utility that you should expose to possible
attackers.
(I'd wager that you shouldn't expose untrusted regexps to possible attackers
ANYHOW, as one could easily build regexps that will run for a long time, easily
causing a DOS attack.)
The second consideration is, of course, that this is about PCRE1, which has
reached EOL. Unless this is also reproducible in PCRE2, it's unlikely that
you'll see a fix for this.
Thanks,
--
You are receiving this mail because:
You are on the CC list for the bug.
