Disabling new D-Bus protocol features by default

[Thiago Macieira]

On Tuesday, 9 de November de 2010 07:26:31 Marcel Holtmann wrote:
> I agree with Lennart here. This is not a D-Bus issue. The applications
> must be able to do input validations. So if they don't validate the
> signature properly, then they are broken on so many levels. This patch
> is not gonna help. It just tries to hide the problem. This is pure
> security by obscurity.

These apps weren't broken before. They became broken when D-Bus upgraded, 
since a new type was added that didn't exist before. It's the spec that 
changed.

> And your security attack vector point exists anyway. I can always send
> D-Bus messages with unknown types. As long as the dbus-daemon supports
> them, they will be forwarded.

Not really. The logic already exists in the negotiation feature: the daemon 
will not forward a type to a connection that didn't negotiate the feature. If 
it did that, the connections that haven't been upgraded yet (old libdbus-1 or 
binding without libdbus-1) will simply disconnect.

> Also you don't wanna put more logic and safety inside the dbus-daemon
> since that is the wrong place. I would actually consider taking more and
> more checks out of the daemon for performance reasons and let the
> applications/bindings deal with it. Relying on only valid data from
> dbus-daemon is just wrong. That is a recipe for disaster.

Maybe so, but that's not what we've done. Right now, we trust the daemon and 
it does have logic to not send the new types. And on the client side, the 
behaviour on seeing new things is to disconnect. Before we talk about removing 
the daemon safeties, we need to fix the clients.

I'm simply moving the control of the negotiation logic to the public.

> > This is a behaviour change in D-Bus 1.4, but I believe it's better to
> > modify the few apps that are changing to support FD passing while we
> > have time than the majority of the apps and the existing, released
> > bindings that don't support the new feature.
> 
> This is too late now. Fedora 14 and the latest Ubuntu are shipping D-Bus
> 1.4 and you would break API for applications already using FD passing
> support.

Yes. For me, it's a security feature, so I think it's worth it. There mustn't 
be more than a couple applications that use this feature right now.

> The right approach is to get the bindings fixed. And also to fix the
> broken application. As stated above they are broken and vulnerable
> anyway. I say clearly that the issue needs to be fixed at the root cause
> and not worked around at some other place.

They are not broken because their security did work before. WE broke it in 
upgrading D-Bus, so it's our fault and we should be the ones to fix it.

You're asking that we fix all applications and all bindings that made the 
assumption that they knew all types possible. You're also asking that no one 
use an old, bundled version of libdbus-1.

If we don't apply this fix, then I think we must *immediately* make libdbus-1 
stop disconnecting when it receives new types from the bus. We can't have 
both.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20101109/93caadf8/attachment.pgp>