public inbox for [email protected]help / color / mirror / Atom feed
BUG #2052: Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities 16+ messages / 10 participants [nested] [flat]
* BUG #2052: Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities @ 2005-11-18 03:54 Ferindo Middleton <[email protected]> 0 siblings, 2 replies; 16+ messages in thread From: Ferindo Middleton @ 2005-11-18 03:54 UTC (permalink / raw) To: [email protected] The following bug has been logged online: Bug reference: 2052 Logged by: Ferindo Middleton Email address: [email protected] 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. Here are the vulnerabilities that were stated (each one has a special Common Vulnerabilities and Exposures (CVE)codes that this IS team had assigned): 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. 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. 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. 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. 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. 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 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. Ferindo ^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities @ 2005-11-18 14:32 Tom Lane <[email protected]> parent: Ferindo Middleton <[email protected]> 1 sibling, 1 reply; 16+ messages in thread From: Tom Lane @ 2005-11-18 14:32 UTC (permalink / raw) To: Ferindo Middleton <[email protected]>; +Cc: [email protected] "Ferindo Middleton" <[email protected]> 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 ^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities @ 2005-11-18 15:08 Stephen Frost <[email protected]> parent: Ferindo Middleton <[email protected]> 1 sibling, 1 reply; 16+ messages in thread From: Stephen Frost @ 2005-11-18 15:08 UTC (permalink / raw) To: Ferindo Middleton <[email protected]>; +Cc: [email protected] * Ferindo Middleton ([email protected]) 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 Attachments: [application/pgp-signature] signature.asc (189B, 2-signature.asc) download ^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept @ 2005-11-22 00:00 Ferindo Middleton Jr <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 16+ messages in thread From: Ferindo Middleton Jr @ 2005-11-22 00:00 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: [email protected]; [email protected]; [email protected] Tom Lane wrote: > "Ferindo Middleton" <[email protected]> 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 ^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept @ 2005-11-24 10:13 Simon Riggs <[email protected]> parent: Stephen Frost <[email protected]> 0 siblings, 2 replies; 16+ messages in thread From: Simon Riggs @ 2005-11-24 10:13 UTC (permalink / raw) To: Tom Lane <[email protected]>; Stephen Frost <[email protected]>; +Cc: [email protected]; Ferindo Middleton <[email protected]>; [email protected] 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 ([email protected]) 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 ^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept @ 2005-11-24 14:09 Peter Eisentraut <[email protected]> parent: Simon Riggs <[email protected]> 1 sibling, 1 reply; 16+ messages in thread From: Peter Eisentraut @ 2005-11-24 14:09 UTC (permalink / raw) To: ; +Cc: Simon Riggs <[email protected]>; [email protected] 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/ ^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept @ 2005-11-24 18:16 Darcy Buskermolen <[email protected]> parent: Peter Eisentraut <[email protected]> 0 siblings, 0 replies; 16+ messages in thread From: Darcy Buskermolen @ 2005-11-24 18:16 UTC (permalink / raw) To: [email protected]; +Cc: Peter Eisentraut <[email protected]>; Simon Riggs <[email protected]> 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 ^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept @ 2005-11-25 17:20 Bruce Momjian <[email protected]> parent: Simon Riggs <[email protected]> 1 sibling, 2 replies; 16+ messages in thread From: Bruce Momjian @ 2005-11-25 17:20 UTC (permalink / raw) To: Simon Riggs <[email protected]>; +Cc: Tom Lane <[email protected]>; Stephen Frost <[email protected]>; [email protected]; Ferindo Middleton <[email protected]>; [email protected] 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 [email protected] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [HACKERS] BUG #2052: Federal Agency Tech Hub Refuses to Accept @ 2005-11-25 18:37 Peter Eisentraut <[email protected]> parent: Bruce Momjian <[email protected]> 1 sibling, 1 reply; 16+ messages in thread From: Peter Eisentraut @ 2005-11-25 18:37 UTC (permalink / raw) To: [email protected]; +Cc: Bruce Momjian <[email protected]>; Simon Riggs <[email protected]>; Tom Lane <[email protected]>; Stephen Frost <[email protected]>; Ferindo Middleton <[email protected]>; [email protected] 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/ ^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept @ 2005-11-25 18:46 Simon Riggs <[email protected]> parent: Bruce Momjian <[email protected]> 1 sibling, 1 reply; 16+ messages in thread From: Simon Riggs @ 2005-11-25 18:46 UTC (permalink / raw) To: Bruce Momjian <[email protected]>; +Cc: Tom Lane <[email protected]>; Stephen Frost <[email protected]>; [email protected]; Ferindo Middleton <[email protected]>; [email protected] 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 ^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept @ 2005-11-25 19:18 Tom Lane <[email protected]> parent: Simon Riggs <[email protected]> 0 siblings, 1 reply; 16+ messages in thread From: Tom Lane @ 2005-11-25 19:18 UTC (permalink / raw) To: Simon Riggs <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Stephen Frost <[email protected]>; [email protected]; Ferindo Middleton <[email protected]>; [email protected] Simon Riggs <[email protected]> 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 ^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [HACKERS] BUG #2052: Federal Agency Tech Hub Refuses to Accept @ 2005-11-25 20:18 Bruce Momjian <[email protected]> parent: Peter Eisentraut <[email protected]> 0 siblings, 1 reply; 16+ messages in thread From: Bruce Momjian @ 2005-11-25 20:18 UTC (permalink / raw) To: Peter Eisentraut <[email protected]>; +Cc: [email protected]; Simon Riggs <[email protected]>; Tom Lane <[email protected]>; Stephen Frost <[email protected]>; Ferindo Middleton <[email protected]>; [email protected] If someone wants to create a separate web page to track fixes related to CVE number, that is fine. My guess is that most people reading the release notes don't care about the CVE numbers themselves (just that each release has all known security bugs fixed), and most bugs that are fixed don't have CVE numbers at commit time. --------------------------------------------------------------------------- Peter Eisentraut wrote: > 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/ > -- Bruce Momjian | http://candle.pha.pa.us [email protected] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept @ 2005-11-25 20:38 Simon Riggs <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 16+ messages in thread From: Simon Riggs @ 2005-11-25 20:38 UTC (permalink / raw) To: pgsql-www; +Cc: Peter Eisentraut <[email protected]>; Magnus Hagander <[email protected]>; Tom Lane <[email protected]>; Bruce Momjian <[email protected]>; Stephen Frost <[email protected]>; Ferindo Middleton <[email protected]> On Fri, 2005-11-25 at 14:18 -0500, Tom Lane wrote: > Simon Riggs <[email protected]> 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... Can I suggest a new web page at http://www.postgresql.org/support/security with links from the support page and a ShortCut from the home page, called "Security Information". The main page title could be Security Information, modelled where appropriate on http://www.us.debian.org/security/ but not too closely. We can put a link to this from release notes, so they will by reference include the security information. Not sure of the submission process/guidelines/format. Can someone send me the link to the FAQ, cos I can't find it on the main wwweb site. Best Regards, Simon Riggs ^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept @ 2005-11-25 20:41 Magnus Hagander <[email protected]> 0 siblings, 0 replies; 16+ messages in thread From: Magnus Hagander @ 2005-11-25 20:41 UTC (permalink / raw) To: Simon Riggs <[email protected]>; pgsql-www; +Cc: Peter Eisentraut <[email protected]>; Tom Lane <[email protected]>; Bruce Momjian <[email protected]>; Stephen Frost <[email protected]>; Ferindo Middleton <[email protected]> > > > 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... > > Can I suggest a new web page at > http://www.postgresql.org/support/security > with links from the support page and a ShortCut from the home > page, called "Security Information". > > The main page title could be Security Information, modelled > where appropriate on http://www.us.debian.org/security/ but > not too closely. I'm working on this. Will let you know when I have something ready to look at. Though I have it at /docs/security for now (with an intended symlink from /security). Perhaps support is better? (trivial to move before the initial commit..) > Not sure of the submission process/guidelines/format. Can > someone send me the link to the FAQ, cos I can't find it on > the main wwweb site. Submission of security bugs, or of pages to the web? ;-) Security bugs info is in the actual documentation pages under reporting bugs. //Magnus ^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [HACKERS] BUG #2052: Federal Agency Tech Hub Refuses to @ 2005-11-25 20:42 John R Pierce <[email protected]> parent: Bruce Momjian <[email protected]> 0 siblings, 1 reply; 16+ messages in thread From: John R Pierce @ 2005-11-25 20:42 UTC (permalink / raw) To: Bruce Momjian <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; [email protected]; Simon Riggs <[email protected]>; Tom Lane <[email protected]>; Stephen Frost <[email protected]>; Ferindo Middleton <[email protected]>; [email protected] Bruce Momjian wrote: > If someone wants to create a separate web page to track fixes related to > CVE number, that is fine. My guess is that most people reading the > release notes don't care about the CVE numbers themselves (just that > each release has all known security bugs fixed), and most bugs that are > fixed don't have CVE numbers at commit time. I think its quite reasonable for the one line description of a postgres bug to reference "CVE-2005-0247 multiple buffer overflows..." or whatever, I guess it kind of depends on which came first... if the CVE security item came first, and was entered into the PGSQL bug tracker, then this makes a LOT of sense. if the CVE folks create their entry AFTER the bug has been entered into PGSQL, it makes less sense. ^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [HACKERS] BUG #2052: Federal Agency Tech Hub Refuses to Accept @ 2005-11-25 22:57 Bruce Momjian <[email protected]> parent: John R Pierce <[email protected]> 0 siblings, 0 replies; 16+ messages in thread From: Bruce Momjian @ 2005-11-25 22:57 UTC (permalink / raw) To: John R Pierce <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; [email protected]; Simon Riggs <[email protected]>; Tom Lane <[email protected]>; Stephen Frost <[email protected]>; Ferindo Middleton <[email protected]>; [email protected] John R Pierce wrote: > Bruce Momjian wrote: > > If someone wants to create a separate web page to track fixes related to > > CVE number, that is fine. My guess is that most people reading the > > release notes don't care about the CVE numbers themselves (just that > > each release has all known security bugs fixed), and most bugs that are > > fixed don't have CVE numbers at commit time. > > I think its quite reasonable for the one line description of a postgres > bug to reference "CVE-2005-0247 multiple buffer overflows..." or > whatever, I guess it kind of depends on which came first... if the CVE > security item came first, and was entered into the PGSQL bug tracker, > then this makes a LOT of sense. if the CVE folks create their entry > AFTER the bug has been entered into PGSQL, it makes less sense. We don't have a bug tracker, see the current FAQ. -- Bruce Momjian | http://candle.pha.pa.us [email protected] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ^ permalink raw reply [nested|flat] 16+ messages in thread
end of thread, other threads:[~2005-11-25 22:57 UTC | newest] Thread overview: 16+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2005-11-18 03:54 BUG #2052: Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities Ferindo Middleton <[email protected]> 2005-11-18 14:32 ` Tom Lane <[email protected]> 2005-11-22 00:00 ` Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept Ferindo Middleton Jr <[email protected]> 2005-11-18 15:08 ` Stephen Frost <[email protected]> 2005-11-24 10:13 ` Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept Simon Riggs <[email protected]> 2005-11-24 14:09 ` Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept Peter Eisentraut <[email protected]> 2005-11-24 18:16 ` Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept Darcy Buskermolen <[email protected]> 2005-11-25 17:20 ` Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept Bruce Momjian <[email protected]> 2005-11-25 18:37 ` Re: [HACKERS] BUG #2052: Federal Agency Tech Hub Refuses to Accept Peter Eisentraut <[email protected]> 2005-11-25 20:18 ` Re: [HACKERS] BUG #2052: Federal Agency Tech Hub Refuses to Accept Bruce Momjian <[email protected]> 2005-11-25 20:42 ` Re: [HACKERS] BUG #2052: Federal Agency Tech Hub Refuses to John R Pierce <[email protected]> 2005-11-25 22:57 ` Re: [HACKERS] BUG #2052: Federal Agency Tech Hub Refuses to Accept Bruce Momjian <[email protected]> 2005-11-25 18:46 ` Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept Simon Riggs <[email protected]> 2005-11-25 19:18 ` Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept Tom Lane <[email protected]> 2005-11-25 20:38 ` Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept Simon Riggs <[email protected]> 2005-11-25 20:41 Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept Magnus Hagander <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox