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

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

> 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.
[snip]

I apologize as the original developer for CREATE CONVERSION. I should
have made these functions only accessible by privileged users when I
developed it.
--
Tatsuo Ishii

REMOVE ME FROM YOUR LIST.......

I am not wanting anymore emails from postgres

E-Mail: comptech(at)envirosolution(dot)com
Web Site: www.envirosolution.com


-----Original Message-----
From: pgsql-announce-owner(at)postgresql(dot)org
[mailto:pgsql-announce-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
Sent: Monday, May 02, 2005 3:07 PM
To: pgsql-announce(at)postgresql(dot)org
Subject: [ANNOUNCE] IMPORTANT: two new PostgreSQL security problems found

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

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005
 

Remove my e-mail id also.


-----Original Message-----
From: pgsql-admin-owner(at)postgresql(dot)org
[mailto:pgsql-admin-owner(at)postgresql(dot)org]On Behalf Of
comptech(at)envirosolution(dot)com
Sent: Tuesday, May 03, 2005 5:51 PM
To: pgsql-admin(at)postgresql(dot)org
Subject: [ADMIN] REMOVE


REMOVE ME FROM YOUR LIST.......

I am not wanting anymore emails from postgres

E-Mail: comptech(at)envirosolution(dot)com
Web Site: www.envirosolution.com


-----Original Message-----
From: pgsql-announce-owner(at)postgresql(dot)org
[mailto:pgsql-announce-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
Sent: Monday, May 02, 2005 3:07 PM
To: pgsql-announce(at)postgresql(dot)org
Subject: [ANNOUNCE] IMPORTANT: two new PostgreSQL security problems found

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

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005
 


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

This is so sad.
How about "please", "thank you", "sorry for being unable to figure out how to 
use the mailing list options".


Nikhil Parva wrote:
> Remove my e-mail id also.
> 
> 
> -----Original Message-----
> From: pgsql-admin-owner(at)postgresql(dot)org
> [mailto:pgsql-admin-owner(at)postgresql(dot)org]On Behalf Of
> comptech(at)envirosolution(dot)com
> Sent: Tuesday, May 03, 2005 5:51 PM
> To: pgsql-admin(at)postgresql(dot)org
> Subject: [ADMIN] REMOVE
> 
> 
> REMOVE ME FROM YOUR LIST.......
> 
> I am not wanting anymore emails from postgres
> 
> E-Mail: comptech(at)envirosolution(dot)com
> Web Site: www.envirosolution.com
> 


-- 
Radu-Adrian Popescu

And the following is even appended to the bottom of their requests:

TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org


AS A NOTE TO OTHERS THAT MAY CONSIDER THIS REQUEST IN THE FUTURE, PLEASE SEE
ABOVE AND THINK BEFORE YOU WRITE!


-----Original Message-----
From: pgsql-admin-owner(at)postgresql(dot)org
[mailto:pgsql-admin-owner(at)postgresql(dot)org]On Behalf Of Radu-Adrian
Popescu
Sent: Tuesday, May 03, 2005 8:39 AM
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: [ADMIN] REMOVE


This is so sad.
How about "please", "thank you", "sorry for being unable to figure out how
to
use the mailing list options".


Nikhil Parva wrote:
> Remove my e-mail id also.
>
>
> -----Original Message-----
> From: pgsql-admin-owner(at)postgresql(dot)org
> [mailto:pgsql-admin-owner(at)postgresql(dot)org]On Behalf Of
> comptech(at)envirosolution(dot)com
> Sent: Tuesday, May 03, 2005 5:51 PM
> To: pgsql-admin(at)postgresql(dot)org
> Subject: [ADMIN] REMOVE
>
>
> REMOVE ME FROM YOUR LIST.......
>
> I am not wanting anymore emails from postgres
>
> E-Mail: comptech(at)envirosolution(dot)com
> Web Site: www.envirosolution.com
>


--
Radu-Adrian Popescu

Hello,

how can it be that there are so many stupid peoples ?

I have had never peoblems to (un)subscribe to postgresql, php, debian,
exim, mutt, procmail, fetchmail and many other Mailinglists.

Greetings
Michelle


Am 2005-05-03 15:39:02, schrieb Radu-Adrian Popescu:
> This is so sad.
> How about "please", "thank you", "sorry for being unable to figure out how 
> to use the mailing list options".

<snip>


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/3/88452356    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 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?
  
An excellent point. Ideally someone (Tom) would be using GnuPG to sign
important messages like this with a digital signature. However, there are
a few checks one could do until that happens. One, compare his headers with
previous ones. Second, check the page at www.postgresql.org for a matching
announcement. Third, wait five minutes for the real Tom Lane to denounce any
fake email sent in his name. :)

If it makes you feel better, I'm 100% sure that was a legitimate email, and
I am going to sign this. :)

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200505040739
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iD8DBQFCeLTwvJuQZxSWSsgRAtACAKDvyylXy1MliqSs8Jsoz7XicXmBagCgoprg
qKPTIVv55E3ne19OGvtOTHM=
=IFvp
-----END PGP SIGNATURE-----