Havoc Pennington discovered a flaw in the way the dbus-daemon applies its
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:
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
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]
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.
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"
Stable for HPPA.
no stable keywords for mips.
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.