Bug 809437 (CVE-2012-1615)

Summary:	CVE-2012-1615 Merely installing sectool grants some permissions to users?
Product:	[Fedora] Fedora	Reporter:	Mathieu Bridon <bochecha>
Component:	sectool	Assignee:	Peter Vrabec <pvrabec>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	16	CC:	colin, dkopecek, jhrozek, jreznik, mschmidt, pvrabec, xbarry
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sectool-0.9.5-7.fc16	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-04-06 21:33:01 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Mathieu Bridon 2012-04-03 11:33:48 UTC

My user is in the wheel group:
  $ id
  uid=1000(mathieu) gid=1000(mathieu) groups=1000(mathieu),10(wheel),990(mock)
  context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

It's not a super user:
  $ systemctl status crond.service
  crond.service - Command Scheduler
	  Loaded: loaded (/lib/systemd/system/crond.service; enabled)
	  Active: active (running) since Mon, 02 Apr 2012 09:48:36 +0800; 1 day and 9h ago
	Main PID: 888 (crond)
  $ systemctl restart crond.service
  Failed to issue method call: Access denied

But it's an "administrator" for PolicyKit and sudo:
  $ sudo systemctl restart crond.service
  [sudo] password for mathieu: 
  $ systemctl status crond.service
  crond.service - Command Scheduler
	  Loaded: loaded (/lib/systemd/system/crond.service; enabled)
	  Active: active (running) since Tue, 03 Apr 2012 19:22:27 +0800; 4s ago
	Main PID: 9932 (crond)
  [... snip ...]

Now, after I install sectool, things change:
  $ systemctl restart crond.service
  $ systemctl status crond.service
  crond.service - Command Scheduler
	  Loaded: loaded (/lib/systemd/system/crond.service; enabled)
	  Active: active (running) since Tue, 03 Apr 2012 19:23:02 +0800; 1s ago
	Main PID: 9954 (crond)
  [... snip ...]


It doesn't seem right that installing a package suddenly grants my user new permissions.

This was first observed by Colin (CC-ed) on Mageia, but I can confirm it also happens on Fedora 16 with sectool-0.9.5-4.fc15.x86_64.rpm

Comment 1 Michal Schmidt 2012-04-03 11:47:08 UTC

Colin also identified the specific file that causes it: org.fedoraproject.sectool.mechanism.conf

When the file is moved away from /etc/dbus-1/system.d/, the bug goes away.

I suspect this piece:
  <policy context="default">
      <allow ...something... />
      <allow send_type="method_call"/>
  </policy>

I don't know the DBus language, but I assume the two <allow> directives are treated independently. So any method calls to anything get allowed :-)

Comment 2 Colin Guthrie 2012-04-03 12:00:48 UTC

Yup, that sounds likely Michal (I'm also don't speak DBus policy, so can't offer any more than that!).

Just for clarity, it doesn't matter what groups your user is in. My test user not in the wheel group could quite happily fiddle about with stuff. This would appear to tie in with Michal's observations too.

Comment 3 Jaroslav Reznik 2012-04-03 14:07:05 UTC

I expect the two allow directives has the desired meaning only while combined in one <allow send_destination="org.fedoraproject.sectool.mechanism" send_type="method_call"/>. This would mean - allow method_call for destination .sectool (but see later).

Because according to dbus-daemon manual page, method_call is denied by default. But "The <deny> element's attributes determine whether the deny "matches" a particular action. If it matches, the action is denied *(unless later rules in the config file allow it)*.". So the allow send_type without a specific destination overrides it.

I checked .conf files for other PK based mechanisms and it's not needed to allow method_call, it's allowed just by allow send_destination. Then the easiest fix is to remove the offending line, sectool works and there's no privileges escalations. I just wonder in how many other dbus services we can find this...

Man page: http://dbus.freedesktop.org/doc/dbus-daemon.1.html

Btw. it's just my observation and it's not clear from man page and I don't speak DBus policy language neither :)

Comment 4 Fedora Update System 2012-04-03 14:54:35 UTC

sectool-0.9.5-7.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/sectool-0.9.5-7.fc17

Comment 5 Fedora Update System 2012-04-03 15:26:55 UTC

sectool-0.9.5-7.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/sectool-0.9.5-7.fc16

Comment 6 Vincent Danen 2012-04-03 22:49:50 UTC

Looks like the patch to fix this is here:

http://pkgs.fedoraproject.org/gitweb/?p=sectool.git;a=blob;f=sectool-0.9.5-dbus.patch;h=aedb3ef7f7e5ab22d5438bfb7eee63489ccf3244;hb=4859832281f0e08c6fbe48fc252c4199a0e9e322

But is not yet upstream.  We'll need to request a CVE for this.

Comment 7 Vincent Danen 2012-04-03 22:55:28 UTC

CVE request and notification on oss-security:

http://openwall.com/lists/oss-security/2012/04/03/8

Comment 8 Kurt Seifried 2012-04-04 03:08:36 UTC

Assigned CVE as per http://www.openwall.com/lists/oss-security/2012/04/04/2

Comment 9 Fedora Update System 2012-04-06 21:33:01 UTC

sectool-0.9.5-7.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Fedora Update System 2012-05-26 07:47:02 UTC

sectool-0.9.5-7.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.