Bug 475201 (CVE-2009-3564)

Summary:	CVE-2009-3564 puppetmasterd does not initialize supplementary groups
Product:	[Other] Security Response	Reporter:	Till Maas <opensource>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	bressers, iboverma, k.georgiou, lutter, matt, maurizio.antillon, mjc, opensource, tmz, vanmeeuwen+fedora, vdanen
Target Milestone:	---	Keywords:	Reopened, Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	0.24.8-4.el4	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-07-25 19:45:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Till Maas 2008-12-08 14:27:45 UTC

Description of problem:
I noticed that puppetmasterd does not initialize its supplementary groups, which may lead to allow puppetmasterd to access files, it should not. E.g. if it is started with "service puppetmaster start", it still has access to all files that allow read access for the supplementary groups of root, e.g. raw disk devices.

I filed an upstream bug report including patches (one needs still to be tested) here:
http://projects.reductivelabs.com/issues/show/1806

Version-Release number of selected component (if applicable):
puppet-0.24.6-1.fc10
puupet-0.24.6-1.el5

How reproducible:
always

Steps to Reproduce:
1. # service puppetmaster start
2. # cat /proc/$(ps --User puppet -o pid | tail -n 1)/status | grep Group
  
Actual results:
The output matches "id  -G root".

Expected results:
The output should match "id  -G puppet", i.e. the process should run with the supplementary groups of puppet.

The default supplementary groups of root include the group disk, which e.g. provides raw read access on disk devices.

Additional info:
I am not sure, whether this really classifies as a security vulnerability, because https://fedoraproject.org/wiki/Security/Classifications only mentions code execution and denial of service, but imho unwanted access to restricted information is a security vulnerability, too.

Comment 1 Fedora Admin XMLRPC Client 2009-03-16 16:52:15 UTC

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 2 Jeroen van Meeuwen 2009-06-24 14:07:53 UTC

Pending upcoming release, a great deal of thanks!

Comment 3 Fedora Update System 2009-08-10 15:04:02 UTC

puppet-0.24.8-4.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/puppet-0.24.8-4.fc10

Comment 4 Fedora Update System 2009-08-10 15:04:27 UTC

puppet-0.24.8-4.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/puppet-0.24.8-4.el5

Comment 5 Fedora Update System 2009-08-10 15:04:51 UTC

puppet-0.24.8-4.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/puppet-0.24.8-4.fc11

Comment 6 Fedora Update System 2009-08-10 15:05:16 UTC

puppet-0.24.8-4.el4 has been submitted as an update for Fedora EPEL 4.
http://admin.fedoraproject.org/updates/puppet-0.24.8-4.el4

Comment 7 Fedora Update System 2009-09-11 23:23:41 UTC

puppet-0.24.8-4.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Fedora Update System 2009-09-11 23:36:29 UTC

puppet-0.24.8-4.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Fedora Update System 2009-09-12 17:51:49 UTC

puppet-0.24.8-4.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Fedora Update System 2009-09-12 17:53:23 UTC

puppet-0.24.8-4.el4 has been pushed to the Fedora EPEL 4 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Till Maas 2009-10-06 08:03:47 UTC

There is now a CVE number assigned for this issue, the metadata for the repositories should probably be updated. The number is: CVE-2009-3564

Comment 12 Vincent Danen 2009-10-07 16:53:34 UTC

Re-opening as this issue also affects Red Hat Enterprise MRG 1.1.

The Red Hat Security Response Team has rated this issue as having low security impact, a future update may address this flaw.

Comment 17 Josh Bressers 2011-07-25 19:45:08 UTC

Statement:

The Red Hat Security Response Team does not currently plan to fix this flaw in MRG.