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.
Note that Postgres' regex library is borrowed lock-stock-and-barrel from Tcl, therefore this issue
probably affects Tcl too.
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?
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?
Tom, I will communicate that information to Will and coordinate communication
towards tcl team.
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.
Public now, lifting embargo:
TCL is not really affected by this as explained in previous Tom's comments.
Upstream have applied the patch to add checks:
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.
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.
This issue was addressed in:
Red Hat Application Stack:
Red Hat Enterprise Linux: