Thread: Security information page
Per some discussion last week, I've put together a page with security information. Basically an introduction written by Simon and a table I pulled together by going through the CVE list and matching it up with our cvs versions. As it makes some statements on behalf of the beleifs of the PGDG (the introduction), I'm giving everybody a good chance to complain and correct before it goes onto the actual website. Oh, and please also point out any incorrectness or missing information in the actual table... The link for the in progress version is http://magnus-master.pgadmin.org/support/security. //Magnus
"Magnus Hagander" <mha@sollentuna.net> writes:
> Per some discussion last week, I've put together a page with security
> information. Basically an introduction written by Simon and a table I
> pulled together by going through the CVE list and matching it up with
> our cvs versions.
: All security issues are always fixed in the next major release, when
: it comes out.
Perhaps "all known security issues..." The statement as made is
hopelessly hubristic.
Please remove the statements about how we will respond within X hours or
days. That has nothing to do with reality. (Reality is that we are
often constrained by CVE publication dates if the fix is trivial, and
if it isn't trivial then it won't be fixed instantly anyway.) I'd lose
the whole paragraph beginning "PGDG's aim ..."
I think the bit about "Our goal is to gain and maintain CVE-compatible
status" is bogus. As near as I can tell, Mitre's definition of CVE
compatibility applies to security products (eg, vulnerability scanners)
which Postgres is not. You could maybe say that this one web page is
something that could apply for CVE compatibility status, but are we
going to jump through those hoops for one web page? Nyet.
The list seems a bit short; did you look through the release notes for
items that seem to be security issues? I suspect there are some that
don't have CVE names.
regards, tom lane
On Sun, 2005-11-27 at 13:46 +0100, Magnus Hagander wrote: > Per some discussion last week, I've put together a page with security > information. Basically an introduction written by Simon and a table I > pulled together by going through the CVE list and matching it up with > our cvs versions. > > As it makes some statements on behalf of the beleifs of the PGDG (the > introduction), I'm giving everybody a good chance to complain and > correct before it goes onto the actual website. Oh, and please also > point out any incorrectness or missing information in the actual > table... > > The link for the in progress version is > http://magnus-master.pgadmin.org/support/security. > Some background to the statements made is probably required also. We touched briefly upon what CVE is in various other posts on hackers. The main CVE website is http://www.cve.mitre.org/ Maintaining CVE-compatible status is likely to be fairly important for security risk management. It will also raise the profile of PostgreSQL as secure software since CVE will list this project on their compatibility page. There are some basic requirements of CVE compatibility: http://www.cve.mitre.org/compatible/ which are described in even more detail here http://www.cve.mitre.org/compatible/requirements.html The link to CVE and the statement of support for CVE are part of those requirements. Those are modelled after the Debian Security Information page at http://www.us.debian.org/security/. That has nothing to do with whether I am or am not a Debian supporter, its just a guide as to how we might make statements to claim CVE-compatibility. I'm happy to be the coordinator for CVE compatibility and fill out the forms to apply for the external review. I'd also be happy if another would like to claim this task. Best Regards, Simon Riggs
On Sun, 2005-11-27 at 12:16 -0500, Tom Lane wrote: > "Magnus Hagander" <mha@sollentuna.net> writes: > > Per some discussion last week, I've put together a page with security > > information. Basically an introduction written by Simon and a table I > > pulled together by going through the CVE list and matching it up with > > our cvs versions. > > : All security issues are always fixed in the next major release, when > : it comes out. > > Perhaps "all known security issues..." The statement as made is > hopelessly hubristic. Agreed. I'm sure Magnus meant that. > Please remove the statements about how we will respond within X hours or > days. That has nothing to do with reality. (Reality is that we are > often constrained by CVE publication dates if the fix is trivial, and > if it isn't trivial then it won't be fixed instantly anyway.) The wording was "typically", there is no "will do this" statement, so its not a binding Service Level Agreement or anything. In terms of what has happened in the last couple of years, I thought it was a reasonable statement. It wasn't meant to be hype. If we can agree a worthwhile and accurate statement I'd ask that we keep it; if we can't then it should go. > I'd lose > the whole paragraph beginning "PGDG's aim ..." The line about our aim was part of the wording required (not exact, I hasten to add) for CVE-compatibility... > I think the bit about "Our goal is to gain and maintain CVE-compatible > status" is bogus. As near as I can tell, Mitre's definition of CVE > compatibility applies to security products (eg, vulnerability scanners) > which Postgres is not. You could maybe say that this one web page is > something that could apply for CVE compatibility status, but are we > going to jump through those hoops for one web page? Nyet. There aren't that many hoops and I have volunteered to do the paperwork. There isn't much else we need to do, apart from maintain the page. If it gets more complex, then I'd agree the effort isn't worth it and withdraw those comments. > The list seems a bit short; did you look through the release notes for > items that seem to be security issues? I suspect there are some that > don't have CVE names. OK. I think we should publish this to -hackers and ask people to check it before we put it up on the site. Best Regards, Simon Riggs
> > Per some discussion last week, I've put together a page > with security > > information. Basically an introduction written by Simon and > a table I > > pulled together by going through the CVE list and matching > it up with > > our cvs versions. > > : All security issues are always fixed in the next major release, when > : it comes out. > > Perhaps "all known security issues..." The statement as made > is hopelessly hubristic. Typo. Thanks. Certainly didn't intend it as anything else than all *known*. > Please remove the statements about how we will respond within > X hours or days. That has nothing to do with reality. > (Reality is that we are often constrained by CVE publication > dates if the fix is trivial, and if it isn't trivial then it > won't be fixed instantly anyway.) I'd lose the whole > paragraph beginning "PGDG's aim ..." Ok. I'll zap it. I guess it can be read as a promise, which it really isn't. "Marketing info" about the speed of patching probably belongs on a different page. > I think the bit about "Our goal is to gain and maintain > CVE-compatible status" is bogus. As near as I can tell, > Mitre's definition of CVE compatibility applies to security > products (eg, vulnerability scanners) which Postgres is not. Um. Not really - products like Debian are CVE compatible (http://www.us.debian.org/security/cve-compatibility), so it's not just for security products. > You could maybe say that this one web page is something that > could apply for CVE compatibility status, but are we going to > jump through those hoops for one web page? Nyet. Right. I'll take that off until such a time as we're further along that process (see Simons mails). Looks better now? > The list seems a bit short; did you look through the release > notes for items that seem to be security issues? I suspect > there are some that don't have CVE names. No, I cheated and did only the CVE list, hoping they did their homework ;-). Limiting the list to 7.3+ cut it dow nquite a bit. I'll go through the release notes and see what I can find. Point-releases only should be enough, right? (since they'd be back-patched from HEAD when found). Thanks for your quick review! //Magnus
On Sun, 2005-11-27 at 12:16 -0500, Tom Lane wrote: > The list seems a bit short; did you look through the release notes for > items that seem to be security issues? I suspect there are some that > don't have CVE names. "Add checks for invalid field length in binary COPY (Tom)" in 7.4.3, should probably be included. If we're not going to describe issues with 7.2 and earlier releases (which is probably reasonable), I think we should back off the claim that "all known" security issues are listed. Personally I think we shouldn't make the latter claim, anyway: for example, whether COALESCE(NULL, NULL) dumping core (fixed in 8.0.3) is a "security issue" is often in the eye of the beholder. From the page: "Our approach covers fail-safe configuration options, a secure and robust database server as well as good integration with other security infrastructure software." What "good integration with other security infrastructure" can PGDG legitimately take credit for? -Neil
On Sun, 2005-11-27 at 21:52 +0100, Magnus Hagander wrote: ..Tom Lane wrote > > I think the bit about "Our goal is to gain and maintain > > CVE-compatible status" is bogus. As near as I can tell, > > Mitre's definition of CVE compatibility applies to security > > products (eg, vulnerability scanners) which Postgres is not. > > Um. Not really - products like Debian are CVE compatible > (http://www.us.debian.org/security/cve-compatibility), so it's not just > for security products. > > > You could maybe say that this one web page is something that > > could apply for CVE compatibility status, but are we going to > > jump through those hoops for one web page? Nyet. > > Right. I'll take that off until such a time as we're further along that > process (see Simons mails). I'll re-raise this as a separate item, later; one step at a time. > Looks better now? And the first step looks very good now. Best Regards, Simon Riggs
> > The list seems a bit short; did you look through the > release notes for > > items that seem to be security issues? I suspect there are > some that > > don't have CVE names. > > "Add checks for invalid field length in binary COPY (Tom)" in > 7.4.3, should probably be included. Yeah. I got that one going through the release notes, had a hard time finding the actual fix that went along with it to figure out what it did. Got a reference from Tom now, so I'll add it right away. > If we're not going to describe issues with 7.2 and earlier > releases (which is probably reasonable), I think we should > back off the claim that "all known" security issues are > listed. The page clearly says "Please note that versions prior to 7.3 are no longer supported and vulnerabilities for these versions are not included in this list". So it should be pretty clear. I'll add something about them not being fixed either :-) > Personally I think we shouldn't make the latter > claim, anyway: for example, whether COALESCE(NULL, NULL) > dumping core (fixed in 8.0.3) is a "security issue" > is often in the eye of the beholder. If we (the PGDG) beleive that is a security issue, it should be on the list. And it should be back-patched to other stable branches - has this been done? > >From the page: > > "Our approach covers fail-safe configuration options, a > secure and robust database server as well as good integration > with other security infrastructure software." > > What "good integration with other security infrastructure" > can PGDG legitimately take credit for? Um, I dunno really :-) Simon? I guess the reference to the fact that we publish all required details for them to scan for it etc... //Magnus
On Sun, 2005-11-27 at 17:35 -0500, Neil Conway wrote: > >From the page: > > "Our approach covers fail-safe configuration options, a secure and > robust database server as well as good integration with other security > infrastructure software." > > What "good integration with other security infrastructure" can PGDG > legitimately take credit for? Kerberos, OpenSSL and LDAP integration, plus with published details of how to link in with MSAD. "Good integration" is my subjective judgement only. If it isn't the feeling of the team, then we can alter it. Best Regards, Simon Riggs
"Magnus Hagander" <mha@sollentuna.net> writes:
>> Personally I think we shouldn't make the latter
>> claim, anyway: for example, whether COALESCE(NULL, NULL)
>> dumping core (fixed in 8.0.3) is a "security issue"
>> is often in the eye of the beholder.
> If we (the PGDG) beleive that is a security issue, it should be on the
> list. And it should be back-patched to other stable branches - has this
> been done?
2005-04-10 16:57 tgl
* src/backend/optimizer/util/: clauses.c (REL7_4_STABLE), clauses.c
(REL8_0_STABLE), clauses.c: Make constant-folding produce sane
output for COALESCE(NULL,NULL), that is a plain NULL and not a
COALESCE with no inputs. Fixes crash reported by Michael
Williamson.
It wasn't back-patched further because earlier versions don't have the
bug.
In general, I think we consider any potential server core dump to be a
security issue, if it can be provoked by unprivileged users. Even if
it's not exploitable in any other way, denial-of-service is still a
security concern.
regards, tom lane
> >> Personally I think we shouldn't make the latter claim, anyway: for > >> example, whether COALESCE(NULL, NULL) dumping core (fixed > in 8.0.3) > >> is a "security issue" > >> is often in the eye of the beholder. > > > If we (the PGDG) beleive that is a security issue, it > should be on the > > list. And it should be back-patched to other stable branches - has > > this been done? > > 2005-04-10 16:57 tgl > > * src/backend/optimizer/util/: clauses.c > (REL7_4_STABLE), clauses.c > (REL8_0_STABLE), clauses.c: Make constant-folding produce sane > output for COALESCE(NULL,NULL), that is a plain NULL and not a > COALESCE with no inputs. Fixes crash reported by Michael > Williamson. > > It wasn't back-patched further because earlier versions don't > have the bug. Rihgt. Added to the list. > In general, I think we consider any potential server core > dump to be a security issue, if it can be provoked by > unprivileged users. Even if it's not exploitable in any > other way, denial-of-service is still a security concern. Seems like a good policy to me. Anybody have anything else to add to the list? //Magnus
> > In general, I think we consider any potential server core > dump to be a > > security issue, if it can be provoked by unprivileged > users. Even if > > it's not exploitable in any other way, denial-of-service is still a > > security concern. > > Seems like a good policy to me. > > Anybody have anything else to add to the list? With no responses after this one about a week ago, I take it people ar efine with me putting this up? If not, please speak up soonest and I'll hold for more updates. //Magnus