Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Ferindo Middleton <fmiddleton(at)verizon(dot)net>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept
Date: 2005-11-24 10:13:14
Message-ID: 1132827194.4347.27.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers pgsql-www

On Fri, 2005-11-18 at 09:32 -0500, Tom Lane wrote:
> All known CVE problems are resolved in 8.0.4.

I was unaware of this. I've looked at the release notes and searched the
archives, but this doesn't seem to be mentioned by CVE number. (The
vulnerabilities and their resolutions are described, just without direct
cross reference to their CVE number.)

Do we have an on-project description of this? If we-as-a-project know
this, it seems straightforward to write it down.

It seems like we need a much clearer resource for security admins to
check our compliance levels. This could be a source of similar
refusal-to-implement PostgreSQL at other installations, so could almost
be regarded as an advocacy issue. Other software projects have been
criticized badly for their security response and info dissemination - I
don't believe that applies here, but it does indicate the general
requirement and its priority. i.e. don't just fix the bugs, tell
everyone you've fixed the bugs.

Or, at very least, put stronger security warnings onto the releases. (My
own advice is always to watch for announcements and stay current).

Thoughts?

Best Regards, Simon Riggs

Stephen's detailed reply to CVE worries copied below for context:
On Fri, 2005-11-18 at 10:08 -0500, Stephen Frost wrote:
> * Ferindo Middleton (fmiddleton(at)verizon(dot)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.
>
> 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.
>
> 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 LOAD
> > extension.
>
> 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.
>
> 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 and
> > earlier may allow attackers to execute arbitrary code via (1) a large number
> > 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.
>
> 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
>
> This appears to have been fixed in 8.0.3.
>
> > CVE-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.
>
> 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Eisentraut 2005-11-24 14:09:09 Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
Previous Message mattias 2005-11-24 07:46:36 Re: BUG #2042: Installation failed

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2005-11-24 10:56:41 Re: MS SQL Server compatibility functions
Previous Message Mario Weilguni 2005-11-24 09:37:45 Re: MS SQL Server compatibility functions

Browse pgsql-www by date

  From Date Subject
Next Message Peter Eisentraut 2005-11-24 14:09:09 Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
Previous Message Joshua D. Drake 2005-11-23 17:01:39 Downloads section