Red Hat Bugzilla – Bug 1191049
CVE-2015-2305 regex: heap overflow in regcomp() on 32-bit architectures
Last modified: 2018-06-29 18:04:11 EDT
A heap buffer overflow was discovered [1] in the regcomp() function of Henry Spencer's regular expression library. The impact of this issue depends on how the affected application uses the regcomp() function. An attacker would have to pass a specially crafted regular expression to the regcomp() function to be able to exploit this issue. Note that this issue only affects 32-bit architectures. [1] https://guidovranken.wordpress.com/2015/02/04/full-disclosure-heap-overflow-in-h-spencers-regex-library-on-32-bit-systems/
Note that on Linux, ghc-regex-posix (Haskell regex-posix library) does not actually use regcomp.c. I just committed: http://pkgs.fedoraproject.org/cgit/ghc-regex-posix.git/commit/?id=468216b9ce33051a7e0878cc430f6f7c791d2763
Do we have some patch for this issue? from the blog it doesn't seem to be obvious.
(In reply to Honza Horak from comment #2) > Do we have some patch for this issue? from the blog it doesn't seem to be > obvious. Hey Honza, dragonflybsd came up with this fix: http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/2841837793bd095a82f477e9c370cfe6cfb3862c which was also used by FreeBSD: https://svnweb.freebsd.org/base?view=revision&revision=278739
Analysis ======== Problematic code is in the regcomp function which is part of regex as shipped in the affected products. Following is the Problematic code in the regex as shipped in mariadb int /* 0 success, otherwise REG_something */ my_regcomp(preg, pattern, cflags, charset) my_regex_t *preg; const char *pattern; int cflags; CHARSET_INFO *charset; { ... 1. sending large string to regcomp() function would make 'len' overgrow to such an extent that would cause 32 bit register/variable overflow. len = strlen((char *)pattern); ... 2. p->ssize does not overflow here and contains number of elements allocated by malloc, which indicates wrong allocated buffer size. p->ssize = (long) (len/(size_t)2*(size_t)3 + (size_t)1); /* ugh */ p->strip = (sop *)malloc(p->ssize * sizeof(sop)); ... }
PHP fix http://git.php.net/?p=php-src.git;a=patch;h=fb04dcf6dbb48aecd8d2dc986806cb58c8ae5282
And PHP bug #69248
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.6 EUS Red Hat Software Collections for Red Hat Enterprise Linux 6.5 EUS Via RHSA-2015:1066 https://rhn.redhat.com/errata/RHSA-2015-1066.html
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.6 EUS Red Hat Software Collections for Red Hat Enterprise Linux 6.5 EUS Via RHSA-2015:1053 https://rhn.redhat.com/errata/RHSA-2015-1053.html
This patch was applied to MySQL to address this issue: https://github.com/mysql/mysql-server/commit/dc45e408250c582eb532417a42cef5b5a8e2fe77 The fix was applied in versions 5.5.45 and 5.6.26. The Spencer regex library used for the REGEXP operator could be subject to heap overflow in some circumstances. (Bug #20642505) http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-26.html http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-45.html It can not be ruled out that Oracle assigned different duplicate CVE for a fix of this issue in MySQL as part of the Oct 2015 CPU. MariaDB picked up the MySQL fix in version 5.5.45: https://github.com/MariaDB/server/commit/dc45e408250c582eb532417a42cef5b5a8e2fe77 MariaDB 10.0 and later do no longer use Henry Spencer's regex library and switched to the use of PCRE in version 10.0.5: https://mariadb.com/kb/en/mariadb/pcre/