Posted on 2005-05-02
Posted by david@fetter.org
We are currently preparing new releases that will correct these
problems in freshly initdb'd installations. However, because
these problems are really incorrect system catalog entries,
updating to a new release will NOT by itself solve the problems
in an existing installation. Instead, it is necessary for the
database administrator to fix the catalog entries manually, as
described below. We are releasing this advisory to encourage
administrators of PostgreSQL installations to perform these fixes
as soon as possible.
Character conversion vulnerability
The more severe of the two errors is that the functions that
support client-to-server character set conversion can be called
from SQL commands by unprivileged users, but these functions are
not designed to be safe against malicious choices of argument
values. This problem exists in PostgreSQL 7.3.* through 8.0.*.
The recommended fix is to disable public EXECUTE access for these
functions. This does not affect normal usage of the functions for
character set conversion, but it will prevent misuse.
To accomplish this change, execute the following SQL command as a
superuser:
UPDATE pg_proc SET proacl = '{=}'
WHERE pronamespace = 11 AND pronargs = 5
AND proargtypes[2] = 'cstring'::regtype;
In 7.3.* through 8.0.*, this should report having updated 90
rows. 7.4 and later will report a "WARNING: defaulting grantor to
user ID 1" which can be ignored.
The above command must be carried out in *each* database of an
installation, including template1, and ideally including
template0 as well. If you do not fix the template databases then
any subsequently created databases will contain the same
vulnerability. template1 can be fixed in the same way as any
other database, but fixing template0 requires additional steps.
First, from any database issue
UPDATE pg_database SET datallowconn = true WHERE datname =
'template0';
Next connect to template0 and perform the pg_proc update.
Finally, do
-- re-freeze template0:
VACUUM FREEZE;
-- and protect it against future alterations:
UPDATE pg_database SET datallowconn = false WHERE datname =
'template0';
tsearch2 vulnerability
The other error is that the contrib/tsearch2 module misdeclares
several functions as returning type "internal" when they do not
have any "internal" argument. This breaks the type safety of
"internal" by allowing users to construct SQL commands that
invoke other functions accepting "internal" arguments. The
consequences of this have not been investigated in detail, but it
is certainly at least possible to crash the backend.
This error affects PostgreSQL 7.4 and later, but only if you have
installed the contrib/tsearch2 module. The recommended fix is to
change the misdeclared functions so that they accept an
"internal" argument and therefore cannot be called directly from
SQL commands.
To do this, execute the following command as a superuser:
UPDATE pg_proc SET proargtypes[0] = 'internal'::regtype
WHERE oid IN (
'dex_init(text)'::regprocedure,
'snb_en_init(text)'::regprocedure,
'snb_ru_init(text)'::regprocedure,
'spell_init(text)'::regprocedure,
'syn_init(text)'::regprocedure
);
This should report 5 rows updated. (If it fails with a message
like "function "dex_init(text)" does not exist", then either
tsearch2 is not installed in this database, or you already did
the update.)
You will need to do this in *each* database in which you have
installed tsearch2, including template1. You need not worry about
template0, however, since it will certainly not contain
tsearch2.
If you frequently install tsearch2 in new databases, you will
also want to modify the tsearch.sql script to declare these
functions as taking type internal in the first place. (The script
fix will be part of the upcoming releases, so you may be able to
wait for those.)
On behalf of the PostgreSQL core committee, I'd like to apologize
for any problems that may arise from these errors.
regards, tom lane
