PostgreSQL, TCL, and others: a Critical bug in the RE engine. Possible vulnerability

Want to draw the attention of abrasheva the possible "vulnerability" in TCL, PostgreSQL, and theoretically in some other systems using modules regular expressions or NFA utility, originally written by Henry Spencer (Henry Spencer). The modified source code, you can find hundreds (at the same Sun Microsystems, UUNET, etc.). And although I don't think there is a bug initially with the distant ' 90s, though, because the code where this error occurs I have Henry, in his old sources not found, test your system still stands.

And so error: it busyloop at compile regular expression of the form ((((( x)*)*)*)*)*. And it is not execution, but compiling, i.e. if there is a check of the validity of the regular season and it is based on the same code NFA have the same infinite loop + 100% cpu usage.

Error found colleagues on the opensource project TCL in all its current versions (including develop). Knowing that Postgres uses a similar API, it was easy to discover that the feeding of this regular expression Postgres leads to a complete hang of the flow (process) fulfills the request.

Error occurs in this group only five or more procedure nesting — i.e., four investment groups are correctly compiled and executed.

Example for PostgreSQL:
the

postgres=# select 1 where 'x'~'(((( x)*)*)*)*';
?column?
----------
1
(1 row)
postgres=# select 1 where 'x'~'((((( x)*)*)*)*)*';

!busyloop!

Example for TCL:
the

% regexp -about {(((( x)*)*)*)*}
4 REG_UEMPTYMATCH
% regexp -about {((((( x)*)*)*)*)*}

!busyloop!

Because this error leads to a locked thread at 100% busy, and due to the fact that there are already bug reports (which, incidentally, is very active shtudiruyutsya hackers and script-kiddis), until the search and will not be released bug fix, I recommend checking out their projects (products) and in the case of a positive result, footcloth the possibility of generating such regular expressions, or regexps foreign input at all.

Today twice dropped in this way, the bug tracker a friend of mine, and then hearing first swearing, then what in the logs could not see anything (the argument post disconnected in the log), I heard the same thanks. Because, forewarned, forearmed.

Of proven vulnerable:
TCL 8.4, 8.5, 8.6 FAILED.
PostgreSQL 8.4, 9.1 FAILED.

do Not subject error:
Python 2.5.2 and 2.7 OK.
UPD: PostgreSQL 9.2.3 OK. (according to the comments of the SW. ' starius).
UPD: PostgreSQL 9.2.1, 9.2.2-2 — OK. (thanks to catlion and sdevalex).

Article based on information from habrahabr.ru