Bug 922567 - VUL-0: libpt2: uses regular expressions (regex) library contains a heap overflow vulnerability
VUL-0: libpt2: uses regular expressions (regex) library contains a heap overf...
Status: RESOLVED INVALID
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Mu Lei
Security Team bot
https://guidovranken.wordpress.com/20...
:
Depends on:
Blocks: CVE-2015-2305
  Show dependency treegraph
 
Reported: 2015-03-16 15:47 UTC by Andreas Stieger
Modified: 2015-03-17 17:08 UTC (History)
2 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Stieger 2015-03-16 15:47:00 UTC
+++ This bug was initially created as a clone of Bug #921950 +++

Guido Vranken reported that regular expressions (regex) originally written by Henry Spencer contains a heap overflow vulnerability.

CWE-122: Heap-based Buffer Overflow

https://guidovranken.wordpress.com/2015/02/04/full-disclosure-heap-overflow-in-h-spencers-regex-library-on-32-bit-systems/
http://www.kb.cert.org/vuls/id/695940

The variable len that holds the length of a regular expression string is "enlarged to such an extent that, in the process of enlarging (multiplication and addition), causes the 32 bit register/variable to overflow." It may be possible for an attacker to use this overflow to change data in memory.

Vulnerable function:
> int /* 0 success, otherwise REG_something */
> regcomp(preg, pattern, cflags)
> regex_t *preg;
> const char *pattern;
> int cflags;
> {

Vulnerable code:
> len = strlen((char *)pattern);
> [...]
> p->ssize = len/(size_t)2*(size_t)3 + (size_t)1; /* ugh */
> p->strip = (sop *)malloc(p->ssize * sizeof(sop));

32-bit systems are affected. It is highly unlikely that 64-bit operating systems would allow such an overflow. (Read: not impossible.)

The library is known to be contained in many different upstream source projects. The code may not be active or used on our platform, e.g. only be used as fallback code.

Found in libpt2: ./src/ptlib/common/regex/regcomp.c
Comment 1 Andreas Stieger 2015-03-16 15:47:27 UTC
spec does not pass --enable-internal-regex

David, could you please check that the package does indeed not use this bundled code?
Comment 2 Swamp Workflow Management 2015-03-16 23:02:40 UTC
bugbot adjusting priority
Comment 3 Mu Lei 2015-03-17 03:58:45 UTC
Could you point me out the name of the affected package? From the topic I guess it's "ptlib2", but I can't find it with osc.
Comment 4 Mu Lei 2015-03-17 04:57:26 UTC
OK, it's libpt2
Comment 5 Andreas Stieger 2015-03-17 08:06:54 UTC
Yes libpt2, subject updated.

Attachment 627001 [details] to parent bug 921950 has an upstream patch from https://github.com/garyhouston/regex/commit/70bc2965604b6b8aaf260049e64c708dddf85334
Comment 7 Andreas Stieger 2015-03-17 17:08:50 UTC
SLE 11 GA and SLE 12 GA build:

$ osc bl standard x86_64 | grep reg
[   46s] checking regex.h usability... yes
[   46s] checking regex.h presence... yes
[   46s] checking for regex.h... yes
[   46s] checking for regcomp... yes

When deleting regcomp.c in the build:

$ osc lbl | grep reg
[   17s] + find -type f -name regcomp.c -print -delete
[   17s] ./src/ptlib/common/regex/regcomp.c
[   19s] checking regex.h usability... yes
[   19s] checking regex.h presence... yes
[   19s] checking for regex.h... yes
[   19s] checking for regcomp... yes

Concluding that the bundled regcomp.c is not used on our platform. Closing issue as not affecting us.