Bugzilla – Bug 775009
VUL-0: CVE-2012-3418: pcp: multiple integer and heap-based buffer overflow flaws
Last modified: 2019-05-01 15:43:06 UTC
There have recently been multiple integer overflows and heap-based buffer overflows flaws reported in pcp via linux-distros (previously vendor sec). Note: ----- This issue is embargoed until the 15th of August 2012. Please keep details inside SUSE and don't use the open build service to prepare patched pkgs.
Original quote from the mail: "Multiple integer and heap-based buffer overflow flaws in PCP (Performance Co-Pilot) libpcp protocol decoding functions. These flaws could lead to daemon crashes or the execution of arbitrary code with root privileges. Many of these flaws can be exploited without requiring the attacker to be auhenticated."
The SWAMPID for this issue is 48666. This issue was rated as important. Please submit fixed packages until 2012-08-16. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
Affects: * SLE11-SP1 * SLE10-SP3 * SLE10-SP4 * SLE-9-SP4
@Stephan, could you please confirm whether the proposal in comment#7 would be acceptable for openSUSE?
Following un-embargo, the pcp-3.6.5 release pachage has been pushed to: https://build.opensuse.org/package/show?package=pcp&project=Base%3ASystem (In reply to comment #7) > In fixing this for openSUSE, I propose we move both 12.1 (currently > pcp-3.5.8-1) and 12.2 (pcp-3.6.4-1 via the updates channel) to pcp-3.6.5, which > will be released at 10am AEST (1AM CET) on Thursday morning. The following maintenance requests have been raised for openSUSE 12.1 & 12.2: https://build.opensuse.org/request/show/130989 https://build.opensuse.org/request/show/130990
we can do version updates for openSUSE here, fine by security. making public too.
(In reply to comment #10) > Following un-embargo, the pcp-3.6.5 release pachage has been pushed to: > https://build.opensuse.org/package/show?package=pcp&project=Base%3ASystem > > (In reply to comment #7) > > In fixing this for openSUSE, I propose we move both 12.1 (currently > > pcp-3.5.8-1) and 12.2 (pcp-3.6.4-1 via the updates channel) to pcp-3.6.5, which > > will be released at 10am AEST (1AM CET) on Thursday morning. I've proposed an update for openSUSE 11.4 to bump the PCP version from 2.5.0 to 3.6.5: https://build.opensuse.org/request/show/131228 > The following maintenance requests have been raised for openSUSE 12.1 & 12.2: > https://build.opensuse.org/request/show/130989 > https://build.opensuse.org/request/show/130990 Is anything further needed from me to move here? I've not seen anything hit http://download.opensuse.org/update/12.1/ .
updates wait for 7 days for community to speak up for QA. we will process the 11.4 request.
openSUSE-SU-2012:1036-1: An update that fixes four vulnerabilities is now available. Category: security (low) Bug References: 775009,775010,775011,775013 CVE References: CVE-2012-3418,CVE-2012-3419,CVE-2012-3420,CVE-2012-3421 Sources used: openSUSE 12.1 (src): pcp-3.6.5-5.4.1
I discussed this bug with Raymund prior to him leaving for vacation, the IBS source is ready for SLE submission pending an ECO. https://build.suse.de/package/show?package=pcp&project=home%3Admdiss%3Abnc775009_pcp_upgrade
openSUSE-SU-2012:1079-1: An update that fixes four vulnerabilities is now available. Category: security (low) Bug References: 775009,775010,775011,775013 CVE References: CVE-2012-3418,CVE-2012-3419,CVE-2012-3420,CVE-2012-3421 Sources used: openSUSE 12.2 (src): pcp-3.6.5-9.9.1
openSUSE-SU-2012:1081-1: An update that fixes four vulnerabilities is now available. Category: security (low) Bug References: 775009,775010,775011,775013 CVE References: CVE-2012-3418,CVE-2012-3419,CVE-2012-3420,CVE-2012-3421 Sources used: openSUSE 11.4 (src): pcp-3.6.5-140.1
Ping, anything I can do here regarding the ECO?
(In reply to comment #27) > Ping, anything I can do here regarding the ECO? Yes, allow me the time to work on it ;)
I think we may need an extra rule to handle upgrades where the devel package is installed. In SLE we currently offer a pcp-devel and base pcp packages. pcp-devel requires libpcp.so.2 provided by the base pcp package, there is no separate libs package. In openSUSE, soon to be SLE, we have a libpcp-devel package (note the name change), the base pcp package, as well as a separate libpcp3 package. Attempting to upgrade pcp while the pcp-devel package is installed results in... Problem: pcp-devel-2.5.0-126.17.x86_64 requires libpcp.so.2()(64bit), but this requirement cannot be provided Solution 1: deinstallation of pcp-devel-2.5.0-126.17.x86_64 Solution 2: do not install pcp-3.6.5-131.1.x86_64 Solution 3: break pcp-devel by ignoring some of its dependencies AFAICT this should be fixable with something like: %package -n libpcp-devel Provides: pcp-devel = %{version} Obsoletes: pcp-devel < %{version}
SUch a change can be told via Provides / Obsoletes Provides: pcp-devel = %version Obsoletes: pcp-devel < %version in libpcp-devel should work.
(In reply to comment #30) > SUch a change can be told via Provides / Obsoletes > > Provides: pcp-devel = %version > Obsoletes: pcp-devel < %version > > in libpcp-devel should work. Pushed again to: https://build.suse.de/project/show?project=home%3Admdiss%3Abnc775009_pcp_upgrade
Could you please undo the pcp-devel -> libpcp-devel rename for SLE? during maintenance phase we shouldn't rename packages, and here there is not even the need to do it. Also, why is pmproxyd still running as root? shouldn't we at least harden the daemon by either running it as non-root or installing a tcpwrapper file that restricts connections from "world"?
(In reply to comment #32) > Could you please undo the pcp-devel -> libpcp-devel rename for SLE? during > maintenance phase we shouldn't rename packages, and here there is not even the > need to do it. Sure we can do that, though it's a pity we can't be in sync with the openSUSE release. > Also, why is pmproxyd still running as root? shouldn't we at least harden the > daemon by either running it as non-root or installing a tcpwrapper file that > restricts connections from "world"? I don't know of the background as to why it's run as root. I'll take a look at the code, but running it as non-root should certainly be an option.
This is an autogenerated message for OBS integration: This bug (775009) was mentioned in https://build.opensuse.org/request/show/133233 Evergreen:11.2 / pcp
(In reply to comment #32) > Could you please undo the pcp-devel -> libpcp-devel rename for SLE? during > maintenance phase we shouldn't rename packages, and here there is not even the > need to do it. See: https://build.suse.de/project/show?project=home%3Admdiss%3Abnc775009_pcp_upgrade_devel Keep in mind we will still have an extra libpcp3 requirement. > Also, why is pmproxyd still running as root? shouldn't we at least harden the > daemon by either running it as non-root or installing a tcpwrapper file that > restricts connections from "world"? PCP 3.6.5 includes http://oss.sgi.com/archives/pcp/2008-09/msg00102.html, and does not run pmproxy as root by default. /var/lib/pcp/config/pmproxy/pmproxy.options specifies the use of the nobody user.
This is an autogenerated message for OBS integration: This bug (775009) was mentioned in https://build.opensuse.org/request/show/133595 Evergreen:11.2 / pcp
Do we also have it in fate? If yes, I'd like to add the release notes snippet there.
(In reply to comment #38) > Do we also have it in fate? If yes, I'd like to add the release notes snippet > there. No FATE. Sorry.
Ok, I'll add this bug as a blocker to the release notes update request bugs. Thanks for the draft version! I changed it slightly (David, I can you please check the text?): Update of Performance Co-Pilot (pcp) The Performance Co-Pilot package (pcp) was updated to version 3.6.5. This update obsoletes libpcp.so.2. As a result, all in-house or third-party applications developed using libpcp.so.2 will need to be re-based against libpcp.so.3. The new library and corresponding development header files are provided as part of the libpcp3-3.6.5 and pcp-devel-3.6.5 package.
(In reply to comment #40) > Ok, I'll add this bug as a blocker to the release notes update request bugs. > Thanks for the draft version! I changed it slightly (David, I can you please > check the text?): The text looks good Karl, a couple of minor comments below... > Update of Performance Co-Pilot (pcp) > > The Performance Co-Pilot package (pcp) was updated to version 3.6.5. This The acronym should be before "package" here, also it should be capitalized (in the title as well): "The Performance Co-Pilot (PCP) package was updated to version 3.6.5. This" > update obsoletes libpcp.so.2. As a result, all in-house or third-party I'd prefer to stick with "any" here, rather than "all". The chances of a customer having such an application is very slim IMO. > applications developed using libpcp.so.2 will need to be re-based against > libpcp.so.3. > > The new library and corresponding development header files are provided > as part of the libpcp3-3.6.5 and pcp-devel-3.6.5 package. Should be plural, "packages".
The package also has a rpm -V error: missing /var/lib/pcp/pmns/.NeedRebuild why is it packaged?
(In reply to comment #42) > The package also has a rpm -V error: > > missing /var/lib/pcp/pmns/.NeedRebuild > > why is it packaged? /var/lib/pcp/pmns/.NeedRebuild is used to trigger a rebuild of the performance metrics namespace on startup. It is checked for and handled by /etc/init.d/pmcd.
then it should be packaged with %missingok are connections to the pcp daemon restricted to any ip ranges or is it at least configurable to run the daemon as non-root (as far as google turns up, running it as non-root is not really recommended though).
(In reply to comment #44) > then it should be packaged with %missingok Thanks, I've committed the change to the home:dmdiss:bnc775009_pcp_upgrade_devel project, as well as Factory devel. > are connections to the pcp daemon restricted to any ip ranges or is it at least > configurable to run the daemon as non-root (as far as google turns up, running > it as non-root is not really recommended though). Host based access control is configurable via the pmcd configuration file, e.g: [access] allow 192.168.155.5 : fetch, store; disallow * : all; We do not currently support running pmcd as non-root.
(In reply to comment #41) Thanks for checking, David. I meant "pcp" as the package name, and thus I'd rather like to avoid capitalization. I'll try a new wording (if that's not ok, please drop me a line). <title>Update of Performance Co-Pilot (Package <literal>pcp</literal>)</title> <para> Performance Co-Pilot (package <literal>pcp</literal>) was updated to version 3.6.5. This update obsoletes <filename>libpcp.so.2</filename>. As a result, any in-house or third-party applications developed using <filename>libpcp.so.2</filename> will need to be re-based against <filename>libpcp.so.3</filename>. </para> <para> The new library and corresponding development header files are provided as part of the <filename>libpcp3-3.6.5</filename> and <filename>pcp-devel-3.6.5</filename> packages. </para> It is in our SVN now. I'll release it together with bug 779575 resp. bug 781781. Please close this bug.
(In reply to comment #46) > (In reply to comment #41) > > Thanks for checking, David. I meant "pcp" as the package name, and thus I'd > rather like to avoid capitalization. I'll try a new wording (if that's not ok, > please drop me a line). New wording looks good, thanks Karl! > It is in our SVN now. I'll release it together with bug 779575 resp. bug > 781781. Please close this bug. I'm waiting for an OK to push what's in home:dmdiss:bnc775009_pcp_upgrade_devel. I'd like to keep the bug open until that time.
(In reply to comment #47) > I'm waiting for an OK to push what's in > home:dmdiss:bnc775009_pcp_upgrade_devel. I'd like to keep the bug open until > that time. That ok with me. I'll try to publish the release notes entry, once this bug is fixed.
(In reply to comment #47) > (In reply to comment #46) > > (In reply to comment #41) > > > > Thanks for checking, David. I meant "pcp" as the package name, and thus I'd > > rather like to avoid capitalization. I'll try a new wording (if that's not ok, > > please drop me a line). > > New wording looks good, thanks Karl! > > > It is in our SVN now. I'll release it together with bug 779575 resp. bug > > 781781. Please close this bug. > > I'm waiting for an OK to push what's in > home:dmdiss:bnc775009_pcp_upgrade_devel. I'd like to keep the bug open until > that time. Can I publish the release notes snippet (c#46) now?
I'm still unsure what the status of this bug report actually is. Can I publish the release notes snippet (c#46) now? Will or David, can you please decide on this?
(In reply to comment #50) > I'm still unsure what the status of this bug report actually is. Can I publish > the release notes snippet (c#46) now? Will or David, can you please decide on > this? The fix has not been released yet, Thomas Biege requested bcn#782967 be fixed before release, which I've not yet addressed.
Well, I agree with Thomas. Let's fix this as well if we are aleady about it anyway. Fixing it would, however, require a CVE to be assigned. Thomas, do you want to request a CVE yourself or do you want me to take care of that?
(In reply to comment #52) > Well, I agree with Thomas. Let's fix this as well if we are aleady about it > anyway. Fixing it would, however, require a CVE to be assigned. Thomas, do > you want to request a CVE yourself or do you want me to take care of that? Matthias, please take care of the CVE ID assignment. Thanks.
(In reply to comment #51) > (In reply to comment #50) > > I'm still unsure what the status of this bug report actually is. Can I publish > > the release notes snippet (c#46) now? Will or David, can you please decide on > > this? > > The fix has not been released yet, Thomas Biege requested bcn#782967 be fixed > before release, which I've not yet addressed. The fixes for bnc#782967 are now upstream, and included in the pcp-3.6.10 tarball released today. The pcp-3.6.10 release also includes support for running PCP daemons as an unprivileged pcp user (some PMDAs still run as root) by default - another concern raised by Thomas upstream. Proceeding towards a SLE release, there are a couple of options that come to mind: 1) Package 3.6.10 as is, with the devel package naming requested in comment#32. This would address CVE-2012-3418, CVE-2012-3420, CVE-2012-3421, CVE-2012-5530, and the root daemon concerns. 2) Package 3.6.5, as was previously released for openSUSE and documented via the ECO, with a back-port of the bnc#782967 changes. This would address the same set of CVE's as option (1), but would not include the non-root daemon changes. My preference is to go with option (1), but option (2) may potentially be slightly less risky, and should not require any changes to the ECO, aside from a short CVE-2012-5530 entry. Thomas, would you be ok with option (1)? Apologies if I'm asking the wrong person.
(In reply to comment #54) > (In reply to comment #51) > > (In reply to comment #50) > > > I'm still unsure what the status of this bug report actually is. Can I publish > > > the release notes snippet (c#46) now? Will or David, can you please decide on > > > this? > > > > The fix has not been released yet, Thomas Biege requested bcn#782967 be fixed > > before release, which I've not yet addressed. > > The fixes for bnc#782967 are now upstream, and included in the pcp-3.6.10 > tarball released today. The pcp-3.6.10 release also includes support for > running PCP daemons as an unprivileged pcp user (some PMDAs still run as root) > by default - another concern raised by Thomas upstream. > > Proceeding towards a SLE release, there are a couple of options that come to > mind: > 1) Package 3.6.10 as is, with the devel package naming requested in comment#32. > This would address CVE-2012-3418, CVE-2012-3420, CVE-2012-3421, CVE-2012-5530, > and the root daemon concerns. > 2) Package 3.6.5, as was previously released for openSUSE and documented via > the ECO, with a back-port of the bnc#782967 changes. This would address the > same set of CVE's as option (1), but would not include the non-root daemon > changes. > > My preference is to go with option (1), but option (2) may potentially be > slightly less risky, and should not require any changes to the ECO, aside from > a short CVE-2012-5530 entry. > > Thomas, would you be ok with option (1)? Apologies if I'm asking the wrong > person. I prefer option (1) too but I fear we have to resend the ECO metioning the new version and other differences from the original pcp package.
(In reply to comment #55) ... > > Thomas, would you be ok with option (1)? Apologies if I'm asking the wrong > > person. > > I prefer option (1) too but I fear we have to resend the ECO metioning the new > version and other differences from the original pcp package. Marcus kindly provided changes to allow for PCP's temp file usage, which have been merged to the IBS project at home:dmdiss:bnc775009_pcp_upgrade_devel_non_root . A proposed PCP 3.6.10 ECO was sent to Daniel, which is awaiting feedback prior to release.
David, you can submit the 3.6.10 packages now. Thanks.
(In reply to comment #61) > David, > you can submit the 3.6.10 packages now. Thanks. Requests 23306 and 23308 were submitted following bnc#796448 resolution. PDB changes are required for the following new packages: ERROR: libpcp3 is missing in PDB (/work/cd/data/pdb/10.1), please create the package there. ERROR: pcp-devel is missing in PDB (/work/cd/data/pdb/10.1), please create the package there. ERROR: pcp-import-iostat2pcp is missing in PDB (/work/cd/data/pdb/10.1), please create the package there. ERROR: pcp-import-mrtg2pcp is missing in PDB (/work/cd/data/pdb/10.1), please create the package there. ERROR: pcp-import-sar2pcp is missing in PDB (/work/cd/data/pdb/10.1), please create the package there. ERROR: pcp-import-sheet2pcp is missing in PDB (/work/cd/data/pdb/10.1), please create the package there. ERROR: perl-PCP-LogImport is missing in PDB (/work/cd/data/pdb/10.1), please create the package there. ERROR: perl-PCP-LogSummary is missing in PDB (/work/cd/data/pdb/10.1), please create the package there. ERROR: perl-PCP-MMV is missing in PDB (/work/cd/data/pdb/10.1), please create the package there. ERROR: perl-PCP-PMDA is missing in PDB (/work/cd/data/pdb/10.1), please create the package there. @Raymund, as the PDB package owner for PCP, could you add the above packages? Let me know otherwise, and I'll run through it.
The new PDB entries exist for 10.1 and 11.1.
I mailed autobuild with the maintained data changes.
Is the prepared release notes entry (Comment 46) still appropriate?
(In reply to comment #66) > Is the prepared release notes entry (Comment 46) still appropriate? Everything except for the version number Karl. 3.6.10 should be used instead of 3.6.5.
Please close this bug, when I can publish the release notes (see the listed blocked bugs below).
released
Update released for: libpcp3, pcp, pcp-debuginfo, pcp-debugsource, pcp-devel, pcp-import-iostat2pcp, pcp-import-mrtg2pcp, pcp-import-sar2pcp, pcp-import-sheet2pcp, perl-PCP-LogImport, perl-PCP-LogSummary, perl-PCP-MMV, perl-PCP-PMDA, permissions, permissions-debuginfo Products: SLE-DEBUGINFO 11-SP2 (i386, ia64, ppc64, s390x, x86_64) SLE-DESKTOP 11-SP2 (i386, x86_64) SLE-SDK 11-SP2 (i386, ia64, ppc64, s390x, x86_64) SLE-SERVER 11-SP2 (i386, ia64, ppc64, s390x, x86_64) SLES4VMWARE 11-SP2 (i386, x86_64)
Update released for: libpcp3, pcp, pcp-debuginfo, pcp-devel, pcp-import-iostat2pcp, pcp-import-mrtg2pcp, pcp-import-sar2pcp, pcp-import-sheet2pcp, perl-PCP-LogImport, perl-PCP-LogSummary, perl-PCP-MMV, perl-PCP-PMDA, permissions Products: SLE-DESKTOP 10-SP4 (i386, x86_64) SLE-SDK 10-SP4 (i386, ia64, ppc, s390x, x86_64) SLE-SERVER 10-SP4 (i386, ia64, ppc, s390x, x86_64)
Update released for: libpcp3, pcp, pcp-debuginfo, pcp-devel, pcp-import-iostat2pcp, pcp-import-mrtg2pcp, pcp-import-sar2pcp, pcp-import-sheet2pcp, perl-PCP-LogImport, perl-PCP-LogSummary, perl-PCP-MMV, perl-PCP-PMDA, permissions Products: SLE-SERVER 10-SP3-TERADATA (x86_64)