Bugzilla Bug 211451

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 an attachment (id=144644) [details]
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.