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: sectoolAssignee: Peter Vrabec <pvrabec>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 16CC: 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 17:33:01 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Mathieu Bridon 2012-04-03 07:33:48 EDT
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 07:47:08 EDT
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 08:00:48 EDT
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 10:07:05 EDT
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 10:54:35 EDT
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 11:26:55 EDT
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 18:49:50 EDT
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 18:55:28 EDT
CVE request and notification on oss-security:

http://openwall.com/lists/oss-security/2012/04/03/8
Comment 8 Kurt Seifried 2012-04-03 23:08:36 EDT
Assigned CVE as per http://www.openwall.com/lists/oss-security/2012/04/04/2
Comment 9 Fedora Update System 2012-04-06 17:33:01 EDT
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 03:47:02 EDT
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.