Bricoleurs,
Just to let you all know that there are security issues with
PostgreSQL that need to be addressed. Information below.
Begin forwarded message:
> From: Tom Lane <tgl@sss.pgh.pa.us>
> Date: May 2, 2005 13:06:38 PDT
> To: pgsql-announce@postgresql.org
> Subject: [ANNOUNCE] IMPORTANT: two new PostgreSQL security problems
> found
> Reply-To: pgsql-admin@postgresql.org
>
>
> 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
>
Just to let you all know that there are security issues with
PostgreSQL that need to be addressed. Information below.
Begin forwarded message:
> From: Tom Lane <tgl@sss.pgh.pa.us>
> Date: May 2, 2005 13:06:38 PDT
> To: pgsql-announce@postgresql.org
> Subject: [ANNOUNCE] IMPORTANT: two new PostgreSQL security problems
> found
> Reply-To: pgsql-admin@postgresql.org
>
>
> 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
>