Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to
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. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
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 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
> > > > 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. Right. This is exactly why it's good to have a list of our own, so ppl can cross reference. > In any case, PostgreSQL already seems to have had 29 CVEs logged: > > http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=postgresql Not quite that many. Several of those are not for postgresql at all, but for third party products *using* postgresql. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
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 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
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 http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. pgpbfTHfOVzX2.pgp Description: PGP signature
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
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/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
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/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
> > 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
> > 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
"Andrew Dunstan" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
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/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
> > 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.pos
