Bug 1303832 (CVE-2016-0773)

Upstream commit:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3bb3f42f3749d40b8d4de65871e8d828b18d4a45

Created postgresql tracking bugs for this issue:

Affects: fedora-all [bug 1306635]

Public via http://www.postgresql.org/about/news/1644/

The issue problem here is an integer overflow in the range() function in regc_locale.c.  It is triggered when doing a case insensitive regular expression match with a character range identifying many characters.  The following code is used to compute the size of the array that will hold all characters specified by the range:

  nchrs = (b - a + 1) * 2 + 4;

a and b are characters for the start and end of the range.  Their difference in multiplied by 2 to ensure there's enough space to store upper- or lower-case counterpart of each character in the range.

All variables are signed int, so this overflows to a small positive value when size of the range is 2^31.  That leads to allocation of an insufficiently sized buffer.

Additionally, it's sufficient to have the range have size of 2^30, which leads to negative nchrs value, and causes the getcvec() function in regc_cvec.c re-use existing cvec with an insufficiently sized buffer (because nchrs <= v->cv->chrspace is true).

There is another problem affecting 32bit systems.  The newcvec() function (also in regc_cvec.c) also fails to protect against integer overflows before doing actual memory allocation.  Each character in the range is represented by a chr type value, which is a 32 bit integer type.  Therefore, the number of characters to be stored is multiplied by sizeof(chr) to get the required buffer size in bytes.  The newcvec() function internally uses variables of type size_t, which is 32 bit type on 32bit systems.  Therefore, a range with 2^29 characters can trigger overflow in newcvec().

On 64bit systems, size_t is 64 bit.  Hence only negative nchars values may trigger integer overflow in newcvec(), as they become large positive after conversion to size_t.  It's unclear if negative nchars is possible in newcvec() given the getcvec()'s attempt to re-use existing cvec when one is already allocated.  On 64bit systems, the newcvec() overflow does not reduce the range size required to trigger overflow.

After cvec is allocated, the range() function initializes its chrs[] array.  It stores every character in the range and optionally its lower- or upper-case counterpart if one exists.  If integer overflow occurred during memory allocation, this initialization needs to write over at least 2GB (2^29 * sizeof(chr)) of memory 32bit systems and 4GB on 64bit systems.  Hence, the initialization complicates exploitation as it is likely to attempt to write into unmapped memory pages, leading to process crash.  PostgreSQL server side processed do not use threads, so other thread won't work with corrupted memory while array initialization is still in progress.

Overall, this looks like a borderline Moderate/Important issue.  Database user with SQL access can easily use this to trigger server restart, achieving code execution seems lot more difficult.

The regex handling code in PostgreSQL comes from the TCL.  This issue did not affect tcl packages as shipped in Red Hat Enterprise Linux and Fedora.  The chr type is 16bit, hence the maximum range size is limited to 2^16, which is not sufficient to trigger the overflow.  Note that TCL can be built with 32bit chr type depending on the value of TCL_UTF_MAX macro.  The default value is 3, which implies the use of 16bit chr.  Other valid value is 6, but that is considered experimental upstream and not recommended.  See tcl.h for details.

It does not seem TCL upstream has corrected this issue yet.  If any of the TCL packages maintainers have account in upstream bug tracker, feel free to open a bug to ensure TCL upstream is aware of the issue.

The TCL regex handling code is also used in SWI-Prolog / XPCE.  It is possible to trigger integer overflow there, but the assert() in addchr() (see regc_cvec.c) seems to prevent buffer overflow and reduces impact to abort.  Notified upstream via:

https://github.com/SWI-Prolog/packages-xpce/issues/2

(In reply to Tomas Hoger from comment #15)
> It does not seem TCL upstream has corrected this issue yet.  If any of the
> TCL packages maintainers have account in upstream bug tracker, feel free to
> open a bug to ensure TCL upstream is aware of the issue.

Created TCL upstream ticket:
http://core.tcl.tk/tcl/tktview/67fcef9acaf767003180ee05b8a35ef8ea6ae049

postgresql-9.4.6-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

postgresql-9.4.6-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2016:0347 https://rhn.redhat.com/errata/RHSA-2016-0347.html

This issue has been addressed in the following products:

  Red Hat Software Collections for Red Hat Enterprise Linux 7.1 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7
  Red Hat Software Collections for Red Hat Enterprise Linux 7.2 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 6.6 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 6

Via RHSA-2016:0348 https://rhn.redhat.com/errata/RHSA-2016-0348.html

This issue has been addressed in the following products:

  Red Hat Software Collections for Red Hat Enterprise Linux 7.1 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7
  Red Hat Software Collections for Red Hat Enterprise Linux 7.2 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 6.6 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 6

Via RHSA-2016:0349 https://rhn.redhat.com/errata/RHSA-2016-0349.html

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2016:0346 https://rhn.redhat.com/errata/RHSA-2016-0346.html

This issue has been addressed in the following products:

  Red Hat Satellite 5.7

Via RHSA-2016:1060 https://rhn.redhat.com/errata/RHSA-2016-1060.html