Unix Technical Forum

Security bugs in tsearch2

This is a discussion on Security bugs in tsearch2 within the pgsql Hackers forums, part of the PostgreSQL category; --> I just noticed that all of tsearch2's "dict init" routines are declared like this: CREATE FUNCTION dex_init(text) returns internal ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > pgsql Hackers

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-11-2008, 03:31 AM
Tom Lane
 
Posts: n/a
Default Security bugs in tsearch2

I just noticed that all of tsearch2's "dict init" routines are declared
like this:

CREATE FUNCTION dex_init(text)
returns internal
as 'MODULE_PATHNAME'
language 'C';

This is really unacceptable, because it breaks the type safety of the
"internal" pseudotype. I quote from datatype.sgml:

The internal pseudo-type is used to declare functions
that are meant only to be called internally by the database
system, and not by direct invocation in a SQL
query. If a function has at least one internal-type
argument then it cannot be called from SQL. To
preserve the type safety of this restriction it is important to
follow this coding rule: do not create any function that is
declared to return internal unless it has at least one
internal argument.

In a database with these functions installed, it will be trivial for
anyone to crash the backend (and perhaps do worse things) since he can
pass the result of dex_init to any function taking an internal argument
--- almost none of which are expecting a dict data structure.

Please change these at once. The best solution might be to declare
an actual "dict" datatype for these functions to return.

Another security issue is that these functions can be used to read any
file that the backend can read. I'm not sure at the moment whether a
bad guy could do anything useful with the result (are the contents of
stoplists exposed anywhere?) but it seems fairly dangerous to allow
arbitrary pathnames in the argument.

A possible short-term solution is to revoke public execute rights on
these functions, so that only superusers can call them.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 03:07 AM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
www.UnixAdminTalk.com