Simon McVittie found a potentially exploitable bug with loading custom dbusmock templates: When a user is tricked into loading a template from a world-writable directory like /tmp, an attacker could run arbitrary code with the user's privileges by putting a crafted .pyc file into that directory. Note that this is highly unlikely to actually appear in practice as custom dbusmock templates are usually shipped in project directories, not directly in world-writable directories. Hence we decided to immediately make this bug public and don't aim for a coordinated release date. So please make this bug public as well. Details are on the linked Launchpad bug. CVE-2015-1326 Upstream fix: https://github.com/martinpitt/python-dbusmock/commit/4e7d0df9093 This is included in the 0.15.1 upstream release: https://launchpad.net/python-dbusmock/trunk/0.15.1
I initially tried to report this as a security bug, but bugzilla would just error 500 on me. Can we subscribe the Fedora/RedHat security team to an existing bug?
(In reply to Martin Pitt from comment #1) > I initially tried to report this as a security bug, but bugzilla would just > error 500 on me. Can we subscribe the Fedora/RedHat security team to an > existing bug? You probably have to have some higher level of mojo ;)
Trying the update to 0.15.1 on Fedora Rawhide and the running of tests seems to end in the disaster ... https://kojipkgs.fedoraproject.org//work/tasks/3162/9713162/build.log ... any idea?
The whole Koji build is http://koji.fedoraproject.org/koji/taskinfo?taskID=9713162
The _dbus_class_table attribute comes from dbus-python. I haven't seen this error yet, we have version 1.2.0. According to https://kojipkgs.fedoraproject.org//work/tasks/3162/9713162/root.log that's the version you have as well.. Was that updated/patched recently in Fedora in a way which could explain this? When did the previous dbusmock build happen?
(In reply to Martin Pitt from comment #5) > Was that updated/patched recently in Fedora in a way which could explain > this? When did the previous dbusmock build happen? That’s the problem … it seems that the last updated version is python-dbusmock-0.11.1-1.fc22, so I am trying to make a huge leap to 0.15.1, I know. See http://koji.fedoraproject.org/koji/packageinfo?packageID=14852 for the history of builds in Fedora.
OOI, does it build on F22 and/or F21 with an older dbus-python? You would probably just grab the single commit for those; but neither that commit nor the other recent changes in later versions don't change the Introspect() method (which accesses self._dbus_class_table), the last change there was in September 2012.
*** Bug 1220745 has been marked as a duplicate of this bug. ***
*** Bug 1220744 has been marked as a duplicate of this bug. ***
Created python-dbusmock tracking bugs for this issue: Affects: fedora-all [bug 1223312] Affects: epel-all [bug 1223313]
Wrt. the build failure: dbus-python's Introspect() does assume that self._dbus_class_table exists; if it wouldn't, the original method would fail as well: http://cgit.freedesktop.org/dbus/dbus-python/tree/dbus/service.py#n756 the koji test failure happens in the overridden def Introspect() which augments self._dbus_class_table with the mocked methods. So this looks like a bug in your dbus-python package somehow? Indeed I can reproduce the failure on a F21 live system. It seems that your dbus-python package has a patch which removes self._dbus_class_table: http://pkgs.fedoraproject.org/cgit/dbus-python.git/tree/object_manager.patch
Created attachment 1029836 [details] patch for building with Fedora-patched dbus-python If you apply this patch to python-dbusmock, it will work correctly with the Fedora-patched dbus-python. I'm happy to apply this patch upstream once the dbus-python patch lands upstream as well.
Created attachment 1304880 [details] koji build log Not sure what to think about this problem.
And of course, I am sorry, that it took so long to get back to this bug.
@Matej: The four timedated test failures were due to output format changes in systemd 215/220, and got fixed in https://github.com/martinpitt/python-dbusmock/commit/f1e2b19bba12fc and https://github.com/martinpitt/python-dbusmock/commit/3d09f9fc27a. The two test_logind failures were due to output format changes in systemd 209 and got fixed in https://github.com/martinpitt/python-dbusmock/commit/39a807c5 . But I suppose this is all moot now in recent Fedoras, which have recent upstream versions?
(In reply to Martin Pitt from comment #15) > But I suppose this is all moot now in recent Fedoras, which have recent > upstream versions? Not in EPEL-7 and F25. With those patches, I have managed to built on both on these, so this bug will be finally closed eventually.
This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products.