Opened 8 years ago

Closed 8 years ago

#7581 closed enhancement (fixed)

pcre-8.38 vulnerability and other fixes.

Reported by: ken@… Owned by: ken@…
Priority: high Milestone: 7.10
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description

I saw a reference to a CVE a while back, and assumed there wouldd be a new release soon. But after getting time to look at this, it seems that upstream are in no hurry - this problem was found by fuzz testing, the sentiment is that the new pcre (variously called 2 or 3 in different places!) has had a lot of fuzz testing and projects ought to move to it. Not much we can do about that.

The vulnerability is CVE-2016-1283, text from https://access.redhat.com/security/cve/CVE-2016-1283 :

The pcre_compile2 function in pcre_compile.c in PCRE 8.38 mishandles the
 /((?:F?+(?:^(?(R)a+\\"){99}-))(?J)(?'R'(?'R'<((?'RR'(?'R'\\){97)?J)?J)(?'R'(?'R'\\){99|(:(?|(?'R')(\\k'R')|((?'R')))H'R'R)(H'R))))))/ 
pattern and related patterns with named subgroups,
which allows remote attackers to cause a denial of
service (heap-based buffer overflow)
or possibly have unspecified other impact via a crafted 
regular expression, as demonstrated by a JavaScript
RegExp object encountered by Konqueror.

Arch patch only for that, and they describe it as "Exploits with advanced Heap Fengshui techniques may allow an attacker to execute arbitrary code in the context of the user running the affected application." I could not work out if that was sarcastic.

Since upstream seem to be in no rush to release, I guess we should at least patch for that. But looking at fedora, they have a lot more post-8.38 fixes:

# Fix compiling comments with auto-callouts, upstream bug #1725,
# fixed in upstream after 8.38
Patch2:     pcre-8.38-Fix-auto-callout-comment-bug.patch
# Fix compiling expressions with negated classes in UCP mode,
# upstream bug #1732, fixed in upstream after 8.38
Patch3:     pcre-8.38-Fix-negated-POSIX-class-within-negated-overall-class.patch
# Fix compiling expressions with an isolated \E between an item and its
# qualifier with auto-callouts, upstream bug #1724,
# fixed in upstream after 8.38
Patch4:     pcre-8.38-Fix-bug-for-isolated-E-between-an-item-and-its-quali.patch
# Fix crash in regexec() if REG_STARTEND option is set and pmatch argument is
# NULL, upstream bug #1727, fixed in upstream after 8.38
Patch5:     pcre-8.38-Give-error-for-regexec-with-pmatch-NULL-and-REG_STAR.patch
# Fix a stack overflow when formatting a 32-bit integer in pcregrep tool,
# upstream bug #1728, fixed in upstream after 8.38
Patch6:     pcre-8.38-Allow-for-up-to-32-bit-numbers-in-the-ordin-function.patch
# Fix compiling expressions with an empty \Q\E sequence between an item and
# its qualifier with auto-callouts, upstream bug #1735,
# fixed in upstream after 8.38
Patch7:     pcre-8.38-Fix-Q-E-before-qualifier-bug-when-auto-callouts-are-.patch
# Fix compiling expressions with global extended modifier that is disabled by
# local no-extended option at the start of the expression just after
# a whitespace, in upstream after 8.38
Patch8:     pcre-8.38-Fix-x-bug-when-pattern-starts-with-white-space-and-x.patch
# Fix possible crash in pcre_copy_named_substring() if a named substring has
# number greater than the space in the ovector, upstream bug #1741,
# in fixed in upstream after 8.38
Patch9:     pcre-8.38-Fix-copy-named-substring-bug.patch
# Fix a buffer overflow when compiling an expression with named groups with
# a group that reset capture numbers, upstream bug #1742,
# fixed in upstream after 8.38
Patch10:    pcre-8.38-Fix-by-hacking-another-length-computation-issue.patch
# Fix a crash in pcre_get_substring_list() if the use of \K caused the start
# of the match to be earlier than the end, upstream bug #1744,
# fixed in upstream after 8.38
Patch11:    pcre-8.38-Fix-get_substring_list-bug-when-K-is-used-in-an-asse.patch
# Fix pcretest for expressions with a callout inside a look-behind assertion,
# upstream bug #1783, fixed in upstream after 8.38
Patch12:    pcre-8.38-Fix-pcretest-bad-behaviour-for-callout-in-lookbehind.patch
# Fix workspace overflow for (*ACCEPT) with deeply nested parentheses,
# upstream bug #1791, fixed in upstream after 8.38
Patch13:    pcre-8.38-Fix-workspace-overflow-for-ACCEPT-with-deeply-nested.patch
# Fix CVE-2016-1283 (heap buffer overflow in handling of nested duplicate named
# groups with a nested back reference), bug #1295386, upstream bug #1767,
# fixed in upstream after 8.38
Patch14:    pcre-8.38-Yet-another-duplicate-name-bugfix-by-overestimating-.patch
# Fix a heap buffer overflow in pcretest causing infinite loop when matching
# globally with an ovector less than 2, bug #1312786, upstream bug #1777,
# fixed in upstream after 8.38
Patch15:    pcre-8.38-Fix-pcretest-loop-for-global-matching-with-an-ovecto.patch
# Fix a non-diagnosis of missing assection after (?(?C) that could corrupt
# process stack, upstream bug #1780, fixed in upstream after 8.38

(patch0 is RPATH, patch1 was rejected upstream, patch16 fixes a typo, apparently not applied upstream)

Should we just fix the CVE, or go for a maximal "upstream fixes" patch using all of patches 2 to 15 from fedora ?

Change History (4)

comment:1 by bdubbs@…, 8 years ago

If we create a maximal patch from Fedora, can you estimate the impact? I see it referenced in 21 BLFS packages and if grep is rebuilt after pcre, it will be used there too.

From your description, it appears that there would not be any negative impact, but I can't be sure.

comment:2 by ken@…, 8 years ago

I took cannot be sure - I have only looked at the lines I copied from the spec file in fedora. All of patches 2 to 15 seem to have an upstream (exim.org, I think) bug number so if there is an application which relies on buggy behaviour, it will break.

comment:3 by ken@…, 8 years ago

Owner: changed from blfs-book@… to ken@…
Status: newassigned

I've batched all the patches together, it builds and tests without problems.

If anything does break, it's early enough in the 7.10 cycle.

comment:4 by ken@…, 8 years ago

Resolution: fixed
Status: assignedclosed

Done as r17122.

Note: See TracTickets for help on using tickets.