Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 209067 (CVE-2008-0674) - dev-libs/libpcre <7.6-r1 Buffer overflow when using specially crafted character classes (CVE-2008-0674)
Summary: dev-libs/libpcre <7.6-r1 Buffer overflow when using specially crafted charact...
Alias: CVE-2008-0674
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High major (vote)
Assignee: Gentoo Security
Whiteboard: C1 [glsa]
: 209060 (view as bug list)
Depends on: 208879
Blocks: 209293
  Show dependency tree
Reported: 2008-02-05 23:55 UTC by Christian Hoffmann (RETIRED)
Modified: 2020-04-04 12:15 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Christian Hoffmann (RETIRED) gentoo-dev 2008-02-05 23:55:57 UTC
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

Ebuild should be in the tree soon (thanks to Opfer), see the other bug for details.
Comment 1 Christian Faulhammer (RETIRED) gentoo-dev 2008-02-05 23:57:51 UTC
*** Bug 209060 has been marked as a duplicate of this bug. ***
Comment 2 Christian Faulhammer (RETIRED) gentoo-dev 2008-02-06 00:01:53 UTC
x86 already stable, adding arches
Comment 3 Christian Faulhammer (RETIRED) gentoo-dev 2008-02-06 00:03:15 UTC
Stabilise dev-libs/libpcre-7.6 please
Comment 4 Chris Gianelloni (RETIRED) gentoo-dev 2008-02-06 00:04:46 UTC
Don't forget to add release@ to security bugs.

Comment 5 Brent Baude (RETIRED) gentoo-dev 2008-02-06 02:12:04 UTC
ppc64 done
Comment 6 jieryn 2008-02-06 03:43:06 UTC
amd64 stable - Package emerges fine, and I remerged grep with USE="pcre". No obvious regressions.

Portage (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.6.1-r0, x86_64)
System uname: 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-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
CFLAGS="-march=athlon64 -O2 -pipe -fomit-frame-pointer -fweb -ftracer"
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"
EMERGE_DEFAULT_OPTS="--verbose --nospinner"
FEATURES="buildpkg collision-protect distlocks fixpackages metadata-transfer multilib-strict parallel-fetch sandbox sfperms strict test unmerge-orphans userfetch"
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-*"
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 softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="peruser" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="fbdev radeon radeonhd vesa vga"

Comment 7 Jeroen Roovers (RETIRED) gentoo-dev 2008-02-06 05:17:25 UTC
Stable for HPPA.
Comment 8 Jonathan Smith (RETIRED) gentoo-dev 2008-02-06 06:40:05 UTC
What is the impact here believed to be? DoS only, or is it believed to allow arbitrary code execution?
Comment 9 Mart Raudsepp gentoo-dev 2008-02-06 08:12:24 UTC
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).
Comment 10 Ferris McCormick (RETIRED) gentoo-dev 2008-02-06 13:24:03 UTC
Sparc stable --- all tests good.
Comment 11 Raúl Porcel (RETIRED) gentoo-dev 2008-02-06 14:39:54 UTC
alpha/ia64 stable
Comment 12 Robert Buchholz (RETIRED) gentoo-dev 2008-02-06 16:00:16 UTC
(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).
Comment 13 Tobias Scherbaum (RETIRED) gentoo-dev 2008-02-06 17:07:10 UTC
ppc stable
Comment 14 Olivier Crete (RETIRED) gentoo-dev 2008-02-10 21:56:04 UTC
amd64 done
Comment 15 Christian Faulhammer (RETIRED) gentoo-dev 2008-02-11 07:05:13 UTC
Security, all security-supported architectures are done.  We should define a severity now.  Hoffie, do you have any details?
Comment 16 Christian Hoffmann (RETIRED) gentoo-dev 2008-02-11 09:09:12 UTC
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. :(
Comment 17 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2008-02-11 20:28:02 UTC
Did anyone try to ask upstream?
Comment 18 Christian Faulhammer (RETIRED) gentoo-dev 2008-02-13 08:13:55 UTC
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.  
Comment 19 Christian Hoffmann (RETIRED) gentoo-dev 2008-02-15 09:33:59 UTC
(In reply to comment #17)
> Did anyone try to ask upstream?
Me not :( -- 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?
Comment 20 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2008-02-15 18:59:49 UTC
I guess this should be rate B1 or even C1?
Comment 21 Christian Hoffmann (RETIRED) gentoo-dev 2008-02-16 15:00:53 UTC
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. :)
Comment 22 Peter Volkov (RETIRED) gentoo-dev 2008-02-23 17:35:36 UTC
Fixed in release snapshot.
Comment 23 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2008-02-26 20:45:39 UTC
Rerating as C1. CVE-2008-0674 mentions code execution.

Request filed.
Comment 24 Robert Buchholz (RETIRED) gentoo-dev 2008-03-04 14:24:58 UTC
(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).

Comment 25 Tobias Heinlein (RETIRED) gentoo-dev 2008-03-19 23:04:47 UTC
GLSA 200803-24