libpcre3 < 7.6 is vulnerable to a buffer overflow resulting in remote code execution bug

dev-libs/libpcre-7.6 fixes a buffer overflow issue:
----
1. A character class containing a very large number of characters with
    codepoints greater than 255 (in UTF-8 mode, of course) caused a buffer
    overflow.
----

Ebuild should be in the tree soon (thanks to Opfer), see the other bug for details.

*** Bug 209060 has been marked as a duplicate of this bug. ***

x86 already stable, adding arches

Stabilise dev-libs/libpcre-7.6 please

Don't forget to add release@ to security bugs.

Thanks!

ppc64 done

amd64 stable - Package emerges fine, and I remerged grep with USE="pcre". No obvious regressions.

Portage 2.1.3.19 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23.9 x86_64)
=================================================================
System uname: 2.6.23.9 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
Timestamp of tree: Wed, 06 Feb 2008 03:00:01 +0000
distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
app-shells/bash: 3.2_p17-r1
dev-java/java-config: 1.3.7, 2.0.33-r1
dev-lang/python: 2.4.4-r6
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 1.12.10-r5
sys-apps/sandbox: 1.2.18.1-r2
sys-devel/autoconf: 2.13, 2.61-r1
sys-devel/automake: 1.4_p6, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils: 2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool: 1.5.24
virtual/os-headers: 2.6.23-r3
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=athlon64 -O2 -pipe -fomit-frame-pointer -fweb -ftracer"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-march=athlon64 -O2 -pipe -fomit-frame-pointer -fweb -ftracer"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--verbose --nospinner"
FEATURES="buildpkg collision-protect distlocks fixpackages metadata-transfer multilib-strict parallel-fetch sandbox sfperms strict test unmerge-orphans userfetch"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LINGUAS="en"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://192.168.1.102/gentoo-portage"
USE="3dnow X a52 aac acl acpi alsa amd64 ao apache2 audiofile autoipd automount avahi bash-completion berkdb bitmap-fonts bzip2 caps cddb cdparanoia cli cracklib crypt dbus directfb dri dvd encode expat fbcon ffmpeg flac fontconfig ftp gdbm gif gnutella gnutls hal iconv icu id3 idea imagemagick imlib ipv6 isdnlog java jpeg kerberos key-screen lame logrotate lzo mad mdnsresponder-compat midi mmap mmx mp3 mpeg mplayer ncurses network nolvm1 nptl nptlonly ogg openft openmp pam pcre perl png pppd pulseadio pulseaudio python quicktime readline reflection samba sdl search-screen session spl sse sse2 ssl subtitles svg swat syslog tcpd test theora threads tiff truetype truetype-fonts type1-fonts unicode vorbis x264 xgetdefault xinetd xml xorg xvid zeroconf zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm sof...

Stable for HPPA.

What is the impact here believed to be? DoS only, or is it believed to allow arbitrary code execution?

What about all tha packages that include and use their own libpcre, rather than use the system one? glib is one such widely used package, for example, as it has some (very useful to it) patches against libpcre that aren't suitable for upstream yet (or some such).

Sparc stable --- all tests good.

alpha/ia64 stable

(In reply to comment #9)
> What about all tha packages that include and use their own libpcre, rather than
> use the system one?

We have created a list of those ebuilds which are affected by bugs in PCRE as they accept remote regex input and will open bugs once it is clear whether this is believed to allow for DoS or code execution (DoS is not an issue in all applications).

ppc stable

amd64 done

Security, all security-supported architectures are done. We should define a severity now. Hoffie, do you have any details?

Nope sorry. I'm just paying attention to pcre because of php (and php's cvs commit list actually made me have a look at the changelog). No further details from me, sorry. :(

Did anyone try to ask upstream?

In bug 209697 some ABI breakage has been reported, that I fixed in dev-libs/libpcre-7.6-r1, direct bump with all stable KEYWORDS from -r0.

(In reply to comment #17)
> Did anyone try to ask upstream?
Me not :(

http://secunia.com/advisories/28923/ -- it looks like it can only be exploited when the user is able to manipulate the regular expression itself. I don't know how common this is, but in PHP/Python or similar you are never supposed to let user input come into the pattern itself, so... I'd say this is rather uncritical for us?

I guess this should be rate B1 or even C1?

Just some clarification of my explanation above:

> 23:11:58 <leio> hmm, couldn't a user be easily enticed to add a vulnerable regex to an app that takes regex inputs? Like an editor find feature or something.
Yes. :)
That's why I actually I asked whether it is common to let user input go into regular expressions. A text editor search function might be a good example, although I don't know what the issue really is, then. The user of the text editor could get the text editor to execute code for him, but someone with access to an editor can probably easily do that without the need for exploiting this vulnerability. :)

Fixed in release snapshot.

Rerating as C1. CVE-2008-0674 mentions code execution.

Request filed.

(In reply to comment #21)
> The user of the text
> editor could get the text editor to execute code for him, but someone with
> access to an editor can probably easily do that without the need for exploiting
> this vulnerability. :)

Having a user doing that input (especially including the shell code necessary to exploit this), would not qualify as a vulnerability. The point is that certain applications might allow users to input regex filters (think: web filters), or execute such input with elevated privileges (think: badly written mail server filter), or a user might open a file containing a regex (think: *office file).

GLSA 200803-24