Security bugs are reported here via bugzilla

[Thomas Houssin <Thomas.Houssin AT gmail.com>]

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