Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities - Mailing list pgsql-bugs

From Stephen Frost
Subject Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities
Date
Msg-id 20051118150850.GW6026@ns.snowman.net
Whole thread Raw
In response to BUG #2052: Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities  ("Ferindo Middleton" <fmiddleton@verizon.net>)
Responses Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-bugs
* Ferindo Middleton (fmiddleton@verizon.net) wrote:
> CVE-2005-0245  Buffer overflow in gram.y for PostgreSQL 8.0.0 and earlier
> may allow attackers to execute arbitrary code via a large number of
> arguments to a refcursor function (gram.y), which leads to a
> heap-based buffer overflow, a different vulnerability than CVE-2005-0247.=
=20=20

I think this was fixed in 8.0.2...

> CVE-2005-0244  PostgreSQL 8.0.0 and earlier allows local users to bypass =
the
> EXECUTE permission check for functions by using the CREATE AGGREGATE
> command.=20=20

This appears to have been fixed in 8.0.1.

> CVE-2005-0227  PostgreSQL (pgsql) 7.4.x, 7.2.x, and other versions allows
> local users to load arbitrary shared libraries and execute code via the L=
OAD
> extension.=20=20

The CVE says it only affected pre-8.0 releases and I'm inclined to
believe it.

> CVE-2005-0246  The intagg contrib module for PostgreSQL 8.0.0 and earlier
> allows attackers to cause a denial of service (crash) via crafted arrays.=
=20

Contrib modules are only an issue if you install them.  If you don't
need them, don't install them.  Don't know if this was fixed but
honestly I expect it was, the Postgres folks don't just sit around on
their hands when CVE's come out.

> CVE-2005-0247  Multiple buffer overflows in gram.y for PostgreSQL 8.0.1 a=
nd
> earlier may allow attackers to execute arbitrary code via (1) a large num=
ber
> of variables in a SQL statement being handled by the read_sql_construct
> function, (2) a large number of INTO variables in a SELECT statement being
> handled by the make_select_stmt function, (3) alarge number of arbitrary
> variables in a SELECT statement being handled
> by the make_select_stmt function, and (4) a large number of INTO variables
> in a FETCH statement being handled by the make_fetch_stmt function, a
> different set of vulnerabilities than CVE-2005-0245.=20=20

Looks like this was fixed in 8.0.2..

> CVE-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=20

This appears to have been fixed in 8.0.3.

> CVE-2005-1410 - The tsearch2 module in PostgreSQL 7.4 through 8.0.x decla=
res
> 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 comma=
nds
> that call other functions that accept internal arguments.

This appears to have been fixed in 8.0.3.

It looks like these were all fixed rather quickly after they were
discovered and brought to the attention of the PostgreSQL team.
http://www.gsa.gov/networx -> Networx Hosting Center -> NHC User
Instructions, Executive Summary.

No software is without bugs.  It would be foolish to assume that you can
deploy a system once and never have to update it for newly discovered
security vulnerabilities.  If you'd like a comparison to a product
they may be allowing elsewhere you might consider looking at Oracle's
track record for fixing security issues.  It's rather... poor.  There
have been a number of articles to this affect on bugtraq recently, you
shouldn't have too much trouble finding good examples.

    Enjoy,

        Stephen

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities
Next
From: "Magnus Hagander"
Date:
Subject: Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities