Havoc Pennington discovered a flaw in the way the dbus-daemon applies its security policy. Ray Strode describes it as such: When evaluating whether or not to invoke a method call, the bus daemon will look at the security policy and try to determine whether or not the caller is allowed access to the method call. Many dbus services have lines in their security policy of the form: <allow send_interface="some.interface.WithMethods"/> to explicitly whitelist the methods of a particular interface for users of a specific policy context. Normally dbus method calls are invoked fully qualified. That is to say the interface the method belongs to is passed to the bus daemon along with the method name of the method call. The bus daemon does not require method calls to be fully qualified, however. If a caller passes just the method with a NULL interface, then the bus daemon will try to find the interface with the corresponding method and invoke the method call on that interface. In these cases, the send_interface attribute of the allow directive is ignored. <allow send_interface="some.interface.WithMethods"/> is interpreted as an implicit <allow/>. This means that if dbus policy file contains any <allow send_interface="..." /> directives for a particular context, then it implicitly allows that context to invoke non-qualified method calls defined for any interface.
Created attachment 144644 [details, diff] CVE-2008-0595.patch Proposed patch.
Adding Doug and Steev as maintainers. Please prepare an updated ebuild and attach it to this bug. Do not commit anything to CVS yet, this bug is confidential until wednesday.
Adding compnerd since I have sporadic internet access and won't be online very often.
Upstream just released dbus 1.1.20 which includes this fix. Also includes the fix for another dbus bug that is currently open. Would like to commit dbus 1.1.20 and mark stable as soon as possible. Would be removing both 1.0.2 and 1.1.4 since they are both vulnerable if possible. Or would the security team prefer we simply patch 1.0.2 and 1.1.4 for now?
I'm on board with steev's plan. dbus 1.1.x series is a shipping version in several mainline distros now and we're hoping to see this as the main version in Gentoo as well.
Additionally D-Bus upstream calls 1.1.x their "Stable Release" and 1.0.x as Legacy.
By the way, this flaw is now public. It's been announced on the dbus ML.
@comment 04: We leave it up to the maintainer wether to patch or bump. Please update URI with link to release announcement. Next time just commit when the issue is public. No reason to wait for security.
(In reply to comment #8) > @comment 04: We leave it up to the maintainer wether to patch or bump. > > Please update URI with link to release announcement. > > Next time just commit when the issue is public. No reason to wait for security. > It's already been committed. I've just been trying to test everything before announcing it. If you want to proceed with making the GLSA. We'll be only supporting 1.1.20 from here out.
Thx Doug. Arches please test and mark stable. Target keywords are: dbus-1.1.20.ebuild:KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ppc64 s390 sh sparc ~sparc-fbsd x86 ~x86-fbsd"
amd64 stable
x86 stable
alpha/ia64/sparc stable
ppc64 done
Stable for HPPA.
no stable keywords for mips.
ppc stable
Fixed in release snapshot.
time for vote. I tend to vote NO.
arm/s390 and sh (not listed here) done by Mike
NO too, closing.
