Skip site navigation (1) Skip section navigation (2)

Re: [ANNOUNCE] IMPORTANT: two new PostgreSQL security problems found

From: Thomas F(dot)O'Connell <tfo(at)sitening(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Cc: pgsql-announce(at)postgresql(dot)org
Subject: Re: [ANNOUNCE] IMPORTANT: two new PostgreSQL security problems found
Date: 2005-05-02 22:09:13
Message-ID: 83afb16522c2793852c5627842f604dd@sitening.com (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-announcepgsql-general
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


In response to

Responses

pgsql-announce by date

Next:From: Markus SchaberDate: 2005-05-02 22:09:56
Subject: Re: [ANNOUNCE] pgtop, display PostgreSQL processes in `top' style
Previous:From: Tom LaneDate: 2005-05-02 20:06:38
Subject: IMPORTANT: two new PostgreSQL security problems found

pgsql-admin by date

Next:From: C. BensendDate: 2005-05-03 01:16:22
Subject: Bad copy-n-paste on character conversion fix - how screwed am I?
Previous:From: regina.beckDate: 2005-05-02 22:02:55
Subject: Regina Beck/MUC/AGIS ist außer Haus. : [ANNOUNCE] IMPORTANT: two new PostgreSQL security problems found

pgsql-general by date

Next:From: Lei SunDate: 2005-05-02 22:52:52
Subject: Security
Previous:From: Devrim GUNDUZDate: 2005-05-02 21:52:56
Subject: Re: [Pgsqlrpms-hackers] Re: 7.3.9 Install Question -

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group