Segfault (.bss overflow) in PCRE

[Tim Starling]

A bug in PCRE was fixed upstream. The issue is a segfault with a pattern like /\x{300000}/ui, e.g.

pcregrep -ui '\x{300000}' < /dev/null

There was no bounds checking on access to some UCD character tables, and insufficient bounds checking in \x character construction. The fix was included in a commit that did a lot of other things:

http://vcs.pcre.org/viewvc?view=revision&revision=774

but I have split out the relevant single-line fix for your convenience. Patch attached.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Limit unicode codepoint to U+10FFFF" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Tim Starling (tstarling)]

Sorry, the correct revision is 781 not 774:

http://vcs.pcre.org/viewvc?view=revision&revision=781
http://vcs.pcre.org/viewvc/code/branches/pcre16/pcre_compile.c?r1=781&r2=780&pathrev=781#l996

[Brian Murray (brian-murray)]

I was unable to create a crash given the command that you provided. Instead I received an error message ...'character value in \x{...} sequence is too large'. I also don't see any crash reports about pcre3, so I think the best thing may just be to wait for the patch to come from upstream.

Is there a particular reason we should patch pcre3 in Ubuntu to fix this? Thanks in advance.

[Tim Starling (tstarling)]

I have confirmed it in Lucid and Precise. It's possible that it's fixed already in Quantal. The message you quote is the expected response when the bug has been fixed (or if the codepoint is more than 7 hexadecimal digits).

Ubuntu's PHP packages link to libpcre3, and some PHP applications (for example the one I work on) allow web users to specify PCRE regex patterns. So it's a DoS vulnerability, and when used with Apache with a threaded MPM, perhaps it could be used to leak private data from unrelated web requests. If the patch is backported to Lucid and Precise, then we'll be able to keep using PCRE from Ubuntu, we won't have to create our own packages.

[Brian Murray (brian-murray)]

Ah, yes I had tested this on a Quantal system. I'll go ahead and get this uploaded to Precise. Would you also like to see it fixed in Lucid?

[Brian Murray (brian-murray)]

This ended up failing to build:

Test 5: API, internals, and non-Perl stuff for UTF-8 support
--- ./testdata/testoutput5 2010-11-20 09:25:30.000000000 -0800
+++ testtry 2012-07-19 11:41:57.478566371 -0700
@@ -50,40 +50,22 @@
 Need char = 128

 /\x{1000000}/8DZ
-------------------------------------------------------------------
- Bra
- \x{1000000}
- Ket
- End
-------------------------------------------------------------------
-Capturing subpattern count = 0
-Options: utf8
-First char = 249
-Need char = 128
+Failed: character value in \x{...} sequence is too large at offset 10

 /\x{4000000}/8DZ
-------------------------------------------------------------------
- Bra
- \x{4000000}
- Ket
- End
-------------------------------------------------------------------
-Capturing subpattern count = 0
-Options: utf8
-First char = 252
-Need char = 128
+Failed: number too big in {} quantifier at offset 10

 /\x{7fffFFFF}/8DZ
 ------------------------------------------------------------------
         Bra
- \x{7fffffff}
+ \x00{7fffFFFF}
         Ket
         End
 ------------------------------------------------------------------
 Capturing subpattern count = 0
 Options: utf8
-First char = 253
-Need char = 191
+First char = 0
+Need char = '}'

 /[\x{ff}]/8DZ
 ------------------------------------------------------------------
@@ -110,10 +92,9 @@
 No need char

 /\x{ffffffff}/8
-Failed: character value in \x{...} sequence is too large at offset 11

 /\x{100000000}/8
-Failed: character value in \x{...} sequence is too large at offset 12
+Failed: number too big in {} quantifier at offset 12

 /^\x{100}a\x{1234}/8
     \x{100}a\x{1234}bcd
FAIL: RunTest

Testing pcregrep
pcregrep version 8.12 2011-01-15
Testing pcregrep UTF-8 features
Testing pcregrep newline settings
PASS: RunGrepTest
===================
1 of 5 tests failed
===================
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory `/«PKGBUILDDIR»'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/«PKGBUILDDIR»'
make: *** [build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
────────────────────────────────────────────────────────────────────────────────
Build finished at 20120719-1142

Finished
────────

E: Build failure (dpkg-buildpackage died)

┌──────────────────────────────────────────────────────────────────────────────┐
│ Cleanup │
└──────────────────────────────────────────────────────────────────────────────┘

Purging /«BUILDDIR»
Not cleaning session: cloned chroot in use

┌──────────────────────────────────────────────────────────────────────────────┐
│ Summary │
└──────────────────────────────────────────────────────────────────────────────┘

Architecture: amd64
Build-Space: 15916
Build-Time: 114
Distribution: precise
Fail-Stage: build
Install-Time: 63
Job: pcre3_8.12-4ubuntu1.dsc
Package: pcre3
Package-Time: 598
Source-Version: 8.12-4ubuntu1
Space: 15916
Status: attempted
Version: 8.12-4ubuntu1
────────────────────────...

[Brian Murray (brian-murray)]

Trying to use the test changes linked to in comment 4 I'm still unable to get testoutput5 to pass.

[Steve Langasek (vorlon)]

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release