[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20171101161136.GA20860@openwall.com>
Date: Wed, 1 Nov 2017 17:11:36 +0100
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: 16362505@...com
Subject: Re: CVE-2017-16231: PCRE 8.41 match() stack overflow; CVE-2017-16232: LibTIFF 4.0.8 memory leaks
On Wed, Nov 01, 2017 at 04:29:32PM +0100, Agostino Sarubbo wrote:
> On mercoled?? 1 novembre 2017 03:26:56 CET ?????? wrote:
> > > [Suggested description]
> > > In PCRE 8.41,
> > > after compiling, a pcretest load test PoC produces a crash overflow
> > > in the function match() in pcre_exec.c because of a self-recursive call.
[...]
> > Use CVE-2017-16231.
>
> I guess that this bug is similar or the same described here:
> https://bugs.exim.org/show_bug.cgi?id=2047
>
> Based on the upstream comment I'd suggest to reject the CVE.
Let's quote that comment in here for discussion and archival:
"Philip Hazel 2017-02-24 15:53:50 GMT
It is very easy to write patterns that have extremely large search
trees, and these can consume a lot of time and/or stack in the current
implementation of pcre2_match(). There are options (*LIMIT_MATCH) and
(*LIMIT_RECURSION) that can be used to limit the amount of stack that is
used. The limits can also be set from pcretest and from programs that
call the library directly. This is all well documented. Fuzzers should
always set these limits much lower than the defaults. See, for example,
the file src/pcre2_fuzzsupport.c in PCRE2.
Also, as I have said several times recently on the list, there will soon
be a new implementation of pcre2_match() that uses heap storage rather
than the stack. The same limits are available to control the amount of
resource used. This should avoid stack overflows, but there will always
be patterns that will take a lot of resources if you don't limit them."
I'm not sure I agree with Philip on this. Based on the comment above,
this is documented behavior and there are limits in place that a program
could use. However, the suggestion that "Fuzzers should always set
these limits much lower than the defaults." might mean that the defaults
are inadequate for safe production use as well, if a pattern might be
untrusted. If fuzzers could hit stack overflow with default limits,
then so could untrusted patterns in production, no? If so, that would
keep this a security issue, and probably a CVE-worthy one, unless the
documentation also states that only trusted patterns are supported.
Alexander
P.S. The original message arrived to oss-security with a Subject of
"Re: [scr412063] PCRE; LibTIFF" preceded by some probably Chinese
characters. As a moderator, I edited the Subject to what it currently
is before approving the message. I regret that the message combines
issues in two unrelated packages, but I never edit message bodies as me
doing so would certainly be too much and potentially inappropriate
(misrepresentation of what someone else posted; even fixing the Subjects
is borderline in that respect). I can only hope that future postings by
16362505 will be better, given this little note. ;-)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
