Bugzilla Bug 228091

** Please note that this issue is confidential and no information should be
disclosed until it is made public, see "Whiteboard" for a date **

Tavis Ormandy writes:

The problem is that when an option is specified at the start of a
pattern, to avoid compiling it unnecessarily into the bytecode it's
passed back up to the caller as if it was specified via pcre_compile()
options, i.e. /(?i)a|b/ == /a|b/i, and as the latter is somewhat easier
to handle, they're made equivalent. This usually works, but when a
pattern contains multiple branches, the new option is accidentally passed
back too far, so when there are multiple branches, only the first gets the
new flag, however on the second compile pass the new flag is always
set, resulting in a mismatch between the size-calculation pass and the
actual compilation pass. The result is pcre overflowing a heap buffer.

 --- pcre_compile.c~     2008-06-12 16:55:22.860930000 +0200
 +++ pcre_compile.c      2008-06-12 16:54:53.647168000 +0200
 @@ -4931,7 +4931,7 @@
                (lengthptr == NULL || *lengthptr == 2 + 2*LINK_SIZE))
             {
             cd->external_options = newoptions;
 +            options = *optionsptr = newoptions;
 -            options = newoptions;
             }
          else
             {

Adding Peter as he is maintaining this package now, sorry for the spam.

Peter, please prepare an ebuild including the patch and attach it to this bug.
Do not commit anything to CVS. We will do prestable testing on this bug.

Created an attachment (id=157447) [edit]
libpcre-7.7-r1.ebuild

Ebuild for patch. Compiles, passes tests.

Created an attachment (id=157449) [edit]
libpcre-7.7-buffer-overflow.patch

Patch as used in ebuild.

Do you want the 7.7 branch to go stable via this bug?

(In reply to comment #4)
> Do you want the 7.7 branch to go stable via this bug?
> 

Yes:
7.7 is mainly a bug-fix release.
No new bugs have been filed since bump.
A bug would have been filed in 8 days anyway.

Arch Security Liaisons, please test the attached ebuild and report it stable on
this bug.
Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 release s390 sh
sparc x86"

CC'ing current Liaisons:
   alpha : yoswink
   amd64 : welp
    hppa : jer
     ppc : dertobi123
   ppc64 : corsair
 release : pva
   sparc : fmccor
     x86 : opfer

Report on alpha:
 - compiles fine
 - tests passed
 - grep built ok with prce support

Green light.

OK for HPPA.

looks good on ppc64

Good to go on amd64.

Looks fine on ia64/sparc/x86

(In reply to comment #11)
> Looks fine on ia64/sparc/x86

 And as I know that Raul is a complete failure, I checked x86, too.  Built
about 40 reverse deps and they seem to work all fine.  So Raul is right by
accident. :)

looks good on ppc

Lifting embargo, Peter please commit straight to stable for the arches that
tested.

Ebuild in tree.

=dev-libs/libpcre-7.7-r1
Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
Already stabled : "alpha amd64 hppa ia64 ppc ppc64 sparc x86"
Missing keywords: "arm m68k s390 sh"

Rerating A1 due to possible remote exploitation vector.

GLSA 200807-03

Upstream committed a different patch, see
http://vcs.pcre.org/viewvc?view=rev&revision=360