From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Security bugs in tsearch2 |
Date: | 2005-01-29 18:17:34 |
Message-ID: | 9102.1107022654@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Rylander | 2005-01-29 18:46:44 | Re: Implementing Bitmap Indexes |
Previous Message | Victor Y. Yegorov | 2005-01-29 17:41:20 | Re: Implementing Bitmap Indexes |