Bug 315231 - (CVE-2007-4769) CVE-2007-4769 postgresql integer overflow in regex code
CVE-2007-4769 postgresql integer overflow in regex code
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 427135 427136 427137 427138 427220 427221 427772 427773 427774
  Show dependency treegraph
Reported: 2007-10-02 07:06 EDT by Tomas Hoger
Modified: 2016-03-04 07:19 EST (History)
2 users (show)

See Also:
Fixed In Version: 8.2.6-1.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-11 17:14:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2007-10-02 07:06:35 EDT
Will Drewry of Google Security Team has reported an integer overflow in regular
expression parsing code, which results in out of bound read and most frequently
in a crash.  This crash affects worker process spawned for database connection,
but may have impact on main prostgresql processes and render database
unavailable for new connections.
Comment 4 Tom Lane 2007-10-02 11:07:44 EDT
Note that Postgres' regex library is borrowed lock-stock-and-barrel from Tcl, therefore this issue 
probably affects Tcl too.
Comment 5 Tomas Hoger 2007-10-02 12:05:04 EDT
Tom, thanks for that info.  It seems that there was more significant change in
regex component between 7.3 and 7.4.  Are both version based on tcl?
Comment 6 Tom Lane 2007-10-02 12:13:54 EDT
No, the Tcl regex code was adopted in 7.4, so RHEL2.1 and RHEL3 are not affected.

I tried to reproduce this in tclsh and could not.  Investigation shows that 'chr' type is unsigned short in a 
default Tcl build, therefore overflow problem cannot happen.  However, in a UCS-4-enabled Tcl build, the 
problem would exist because then they type 'chr' as unsigned int.  So we ought to let them know about 
this --- do we have any Tcl security contacts?
Comment 7 Tomas Hoger 2007-10-02 12:31:54 EDT
Tom, I will communicate that information to Will and coordinate communication
towards tcl team.
Comment 8 Tom Lane 2007-10-02 13:15:32 EDT
Also, I've confirmed that the infinite loops Will reported (CVE-2007-4772) do happen in Tcl, so even if the 
crash is a low-priority problem for them, the looping is an issue.

If you file separate bugzillas for the Tcl forms of these problems, would you put me on the cc list?  I'd 
really like to coordinate fixes with them, particularly for the looping --- there is not anyone in the 
Postgres project who's intimate with that code, so it will probably take us awhile to figure it out if we have 
to fix it by ourselves.
Comment 16 Tomas Hoger 2008-01-07 08:54:47 EST
Public now, lifting embargo:

Comment 18 Tomas Hoger 2008-01-08 04:38:57 EST
TCL is not really affected by this as explained in previous Tom's comments. 
Upstream have applied the patch to add checks:

Comment 21 Fedora Update System 2008-01-11 17:13:58 EST
postgresql-8.2.6-1.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 22 Fedora Update System 2008-01-11 17:24:08 EST
postgresql-8.2.6-1.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.