BUG #2052: Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities

"Ferindo Middleton" <fmiddleton@verizon.net> writes:

This bug report involves more than one proposed bug. I work at a federal
government agency. The information technology division at this agency
refuses to allow the database version 8.0.4 on their network because of
several security vulnerabilities they noticed when testing the software
application.

They obviously haven't "tested" anything --- they are merely reading the
CVE reports for old Postgres versions. All known CVE problems are
resolved in 8.0.4.

(If they were actually serious about security, they wouldn't be letting
you run Windows 2000 inside their network, but I digress.)

regards, tom lane

Bug reference: 2052
Logged by: Ferindo Middleton
Email address: fmiddleton@verizon.net
PostgreSQL version: 8.0.4
Operating system: Windows 2000
Description: Federal Agency Tech Hub Refuses to Accept
Postgresql on
Network because of Security Vulnerabilities
Details:

This bug report involves more than one proposed bug. I work
at a federal government agency. The information technology
division at this agency refuses to allow the database version
8.0.4 on their network because of several security
vulnerabilities they noticed when testing the software
application. The database would run on a Windows 2000
Professional computer system. The division I work for wants
to use the database as a backend to a set Java Server Pages I
developed to be served via Apache Tomcat. My application
works great with PostgreSQL but the problem is getting the IS
team at this agency to accept PostgreSQL db. I know nothing
about hacking PostgreSQL. I am merely know how to install,
setup, run the database and write JSP applications to us the
database in the background so these security vulnerabilities
are beyond the scope of my own understanding of the database
from a mere admin/user level.

I am going to paste below the feedback I received concerning
the vulnerabilities of the database in hopes that The
PostgreSQL Global Development Group would consider looking
into each stated flaw. I believe that resolution of these
vulnerabilities would be a major achievement of our database
management system and possibly open the software up to more
government acceptance and utilization, which I believe it is lacking.

I beleive every single one of these bugs is fixed in the currently
available releases.
So if you get 8.0.4 or 8.1.0, you're fine for any of these.

(Oh, and what *do* they allow? Oracle, for example, has had a *lot* more
security vulnerabilities during the same time, some of which aren't even
patched yet.. And they can't seriously have a zero-bugs-even-if-fixed
policy, because then they couldn't install *anything*...)

//Magnus

* 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.

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

Tom Lane wrote:

"Ferindo Middleton" <fmiddleton@verizon.net> writes:

This bug report involves more than one proposed bug. I work at a federal
government agency. The information technology division at this agency
refuses to allow the database version 8.0.4 on their network because of
several security vulnerabilities they noticed when testing the software
application.

They obviously haven't "tested" anything --- they are merely reading the
CVE reports for old Postgres versions. All known CVE problems are
resolved in 8.0.4.

(If they were actually serious about security, they wouldn't be letting
you run Windows 2000 inside their network, but I digress.)

regards, tom lane

Thanks for your support with this. I had presented the IT support team
at this agency with the information you all provided that these
CVEs/bugs were resolved in previous versions to 8.0.4 and they suddenly
argued that it wasn’t the CVE’s that were the problem (without admitting
that they never really tested 8.0.4 in the first place)… I’m sorry if I
wasted anybody’s time or irritated anyone by assuming that these bugs
were actually valid in 8.0.4… I’m starting to get tied up in a bunch of
bureaucratic tape dealing with these people. I think their just scared
of having to deal with the support overhead they think they'll have to
assume if they introduce another DBMS on their network…

Thank you,

Ferindo Middleton

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:

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?

How about a simlpe webpage that has more or less a table with:
CVE-number | present in releases | fixed in releases
CVE-number | present in releases | fixed in releases
CVE-number | present in releases | fixed in releases

etc?

Perhaps also a link to an advisory of our own?

Yeah, looking around a bit, it looks like unless you're on -hackers,
it's kinda hard to know. Any reason we don't publish security pulletins
to bugtraq for example?

//Magnus

Simon Riggs wrote:

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.)

We really should write the CVE numbers into the commit messages and the
release notes.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Thu, 2005-11-24 at 15:09 +0100, Peter Eisentraut wrote:

We really should write the CVE numbers into the commit messages and the
release notes.

I think that would be good.

On Thu, 2005-11-24 at 12:35 +0100, Magnus Hagander 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.

How about a simple webpage that has more or less a table with:
CVE-number | present in releases | fixed in releases
CVE-number | present in releases | fixed in releases
CVE-number | present in releases | fixed in releases

..and I think we should do this too.

Have to say I'm a bit worried about overloading Tom and Bruce, who write
most of the security patches and relevant release notes.

Anybody else volunteer to maintain the web page?

Best Regards, Simon Riggs

Simon Riggs said:

On Thu, 2005-11-24 at 15:09 +0100, Peter Eisentraut wrote:

We really should write the CVE numbers into the commit messages and
the release notes.

I think that would be good.

A security page on the web site that summarised the info would be good too.

cheers

andrew

"Andrew Dunstan" <andrew@dunslane.net> writes:

On Thu, 2005-11-24 at 15:09 +0100, Peter Eisentraut wrote:

We really should write the CVE numbers into the commit messages and
the release notes.

A security page on the web site that summarised the info would be good too.

Not to mention a lot easier to create after-the-fact ...

regards, tom lane

On Thursday 24 November 2005 06:09, Peter Eisentraut wrote:

Simon Riggs wrote:

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.)

We really should write the CVE numbers into the commit messages and the
release notes.

I also belive that we should have these referenced visably on the website much
the same way apache does:
http://httpd.apache.org/security_report.html

--
Darcy Buskermolen
Wavefire Technologies Corp.

http://www.wavefire.com
ph: 250.717.0200
fx: 250.763.1759

Simon Riggs wrote:

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).

Well, as the original poster mentioned, they were looking for a reason
_not_ to use PostgreSQL, and if that is the goal, you can find a reason,
error numbers or not.

I am not excited about referencing error numbers from someone else. We
know our errors better than anyone else, so I don't see the point.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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).

Well, as the original poster mentioned, they were looking for
a reason _not_ to use PostgreSQL, and if that is the goal,
you can find a reason, error numbers or not.

Sure - but it can be used as a good tool to prove such a person *wrong*.
Because it's an easy to find place.

I am not excited about referencing error numbers from someone
else. We know our errors better than anyone else, so I don't
see the point.

Point 1: Where do you go today to find a list of fixed security issues
in PostgreSQL, and where they are fixed? There is no central list of
this. This is the important point - to create such a list. (IMHO, of
course)

Point 2: CVE is pretty much the industry standard for naming
vulnerabilities. This is what people *use*. There's no reason *not* to
provide it as a cross reference. But sure, we shouldn't list only the
ones that have CVE numbers - if there are any that doesn't, they should
be listed as well. If you read up on CVE you will find that their only
function is to provide a common way to refer to a vulnerability, no
matter who talks about it, without any risk to get it wrong.

//Magnus

We really should write the CVE numbers into the commit messages and
the release notes.

I think that would be good.

That requires the CVE number to be available at the time of commit. Not
sure if it'll always be. But if it is, it's certainly a good idea to put
it in.

How about a simple webpage that has more or less a table with:
CVE-number | present in releases | fixed in releases
CVE-number | present in releases | fixed in releases
CVE-number | present in releases | fixed in releases

..and I think we should do this too.

Have to say I'm a bit worried about overloading Tom and
Bruce, who write most of the security patches and relevant
release notes.

Anybody else volunteer to maintain the web page?

While I think it would be a good idea for someone on -core to actually
be responsible for such a list, I can certainly create and maintain the
page. With our track record of security issues, it doesn't seem that it
should be all that much work...

//Magnus

Bruce Momjian wrote:

I am not excited about referencing error numbers from someone else.
We know our errors better than anyone else, so I don't see the point.

The point is, *we* might know our error numbers, but the rest of the
world doesn't.

And CVE isn't just "someone". A large number of security groups,
government agencies, and OS distributors are involved there. Using CVE
numbers, the public can, say, correlate bugtraq or CERT announcements
or Red Hat or Debian bugs to PostgreSQL patches and releases.
Copy-and-pasting the CVE number into the patch message or release note
entry really isn't that much to ask for that service.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Magnus Hagander wrote:

Point 2: CVE is pretty much the industry standard for naming
vulnerabilities. This is what people *use*. There's no reason *not*
to provide it as a cross reference. But sure, we shouldn't list only
the ones that have CVE numbers - if there are any that doesn't, they
should be listed as well.

Actually, if there are any that don't have a CVE number, then we should
simply ask for one to be assigned.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Fri, Nov 25, 2005 at 07:30:12PM +0100, Magnus Hagander wrote:

We really should write the CVE numbers into the commit messages and
the release notes.

I think that would be good.

That requires the CVE number to be available at the time of commit. Not
sure if it'll always be. But if it is, it's certainly a good idea to put
it in.

I think that depends on who discovers it. CVEs are assigned even if
it's not clear that the vulnerability is exploitable. In anycase, some
distributors (like Debian) already track CVEs on your behalf. In
general they refer to the CVE when releasing fixes.

In any case, PostgreSQL already seems to have had 29 CVEs logged:

http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=postgresql

If you follow the links you can find all the vendor security notices.
In many cases they provide the link to the -announce or -committers
email.

If it's too much work for CORE, maybe someone could download that list
every now and then, verify they've been fixed and check it into the
tree somewhere under SECURITY or some such. If they could be linked to
commit message, all the better.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

On Fri, 2005-11-25 at 12:20 -0500, Bruce Momjian wrote:

Simon Riggs wrote:

On Fri, 2005-11-18 at 09:32 -0500, Tom Lane wrote:

All known CVE problems are resolved in 8.0.4.

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.

Well, as the original poster mentioned, they were looking for a reason
_not_ to use PostgreSQL, and if that is the goal, you can find a reason,
error numbers or not.

I think that's true, but it should be our goal to remove all excuses so
that people have to face up to the real issues. I see this as advocacy
in many ways.

I am not excited about referencing error numbers from someone else. We
know our errors better than anyone else, so I don't see the point.

I think if you don't want to put those on the release notes, thats fine;
we know you're busy. Others have spoken in favour of a web page,
separate from the release notes, and as Tom points out its easier to do
it that way retrospectively anyway.

*We* do know our errors, but thats not the point. CVE is becoming an
accepted standard for referring to security exposures and we should
follow this trend. http://www.cve.mitre.org/about/introduction.html
CVE isn't just somebody else's bugtrack numbers, they're big.
Debian, Gentoo, RedHat, IBM, CA etc already do this.

Unless somebody else wants to do this, I'll discuss on -www how we can
get a page up on the .org site with this info on, so that we can be "CVE
compatible".

Best Regards, Simon Riggs

Simon Riggs <simon@2ndquadrant.com> writes:

Unless somebody else wants to do this, I'll discuss on -www how we can
get a page up on the .org site with this info on, so that we can be "CVE
compatible".

IMHO we should do that in any case, whether or not we mention CVEs
in our release notes or CVS logs in the future. So go for it...

regards, tom lane