Skip to Content.
Sympa Menu

sm-security - [SM-Security] two problems found in postgresql

sm-security AT lists.ibiblio.org

Subject: Security bugs are reported here via bugzilla

List archive

Chronological Thread  
  • From: Thomas Houssin <Thomas.Houssin AT gmail.com>
  • To: sm-security AT lists.ibiblio.org
  • Subject: [SM-Security] two problems found in postgresql
  • Date: Sat, 21 May 2005 14:08:22 +0200

Synopsis
========
PostgreSQL is vulnerable to Denial of Service attacks and possibly
allows unprivileged users to gain administrator rights.

Background
==========
PostgreSQL is a sophisticated Object-Relational DBMS, supporting almost
all SQL constructs, including subselects, transactions and user defined
types and functions.

Description
===========
CAN-2005-1409 :
PostgreSQL 7.3.x through 8.0.x gives public EXECUTE access to certain
character conversion functions, which allows unprivileged users to call
those functions with malicious values, with unknown impact, aka the
"Character conversion vulnerability."

CAN-2005-1410 :
The tsearch2 module in PostgreSQL 7.4 through 8.0.x declares the (1)
dex_init, (2) snb_en_init, (3) snb_ru_init, (4) spell_init, and (5)
syn_init functions as "internal" even when they do not take an internal
argument, which allows attackers to cause a denial of service
(application crash) and possibly have other impacts via SQL commands
that call other functions that accept internal arguments.


Affected packages
=================
postgresql in all grimoires is affected.
This is now fixed in devel, test, stable-rc and stable grimoire.

Resolution
==========
All postgresql users should upgrade to the latest available version:
#scribe update
#cast -c postgresql

Manual intervention is required to fix existing databases. The HISTORY
file explains how to fix the problem :

A dump/restore is not required for those running 8.0.X. However, it is
one possible way of handling two significant security problems that
have been found in the initial contents of 8.0.X system catalogs. A
dump/initdb/reload sequence using 8.0.3's initdb will automatically
correct these problems.

If you wish not to do an initdb, perform the following procedures
instead. As the database superuser, do:
BEGIN;
UPDATE pg_proc SET proargtypes[3] = 'internal'::regtype
WHERE pronamespace = 11 AND pronargs = 5
AND proargtypes[2] = 'cstring'::regtype;
-- The command should report having updated 90 rows;
-- if not, rollback and investigate instead of committing!
COMMIT;

Next, if you have installed "contrib/tsearch2", do
BEGIN;
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
);
-- The command should report having updated 5 rows;
-- if not, rollback and investigate instead of committing!
COMMIT;

If this command 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.

The above procedures 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 errors. 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 above repair procedures.
Finally, do
-- re-freeze template0:
VACUUM FREEZE;
-- and protect it against future alterations:
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';


--
Thomas Houssin

Security Team Lead : Source Mage GNU/Linux http://www.sourcemage.org
Key fingerprint = 3CB8 3FC4 840D B272 E623 BCB8 54DB F4E3 4240 4C36
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x42404C36



Attachment: signature.asc
Description: OpenPGP digital signature



  • [SM-Security] two problems found in postgresql, Thomas Houssin, 05/21/2005

Archive powered by MHonArc 2.6.24.

Top of Page