Re: [ANNOUNCE] IMPORTANT: two new PostgreSQL security problems found - Mailing list pgsql-admin

Considering that this is a security-related system catalog update, is
there any way of providing some sort of signature for a message like
this such that the community can feel that issuing some arcane commands
as a superuser won't open a hole rather than close one?

This is the first time I've seen an announcement of this sort regarding
PostgreSQL, and I'm just curious about the release mechanism for it.

I doubt if anyone is spoofing Tom, but in an era of phishing and
spoofing, one can't be too sure, especially if one is concerned about
security...

-tfo

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Strategic Open Source: Open Your i™

http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005

On May 2, 2005, at 3:06 PM, Tom Lane wrote:

> Two serious security errors have been found in PostgreSQL 7.3 and newer
> releases.  These errors at least allow an unprivileged database user to
> crash the backend process, and may make it possible for an unprivileged
> user to gain the privileges of a database superuser.
>
> 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
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings