CVE-2014-3477

What it actually does

The dbus-daemon mishandles AccessDenied responses by delivering them to the target service rather than the originating client, causing the service to abort initialization or leak timing information.

Why it matters to the business

Local denial-of-service conditions can interrupt dependent system services, leading to degraded availability on hosts running vulnerable D-Bus versions; the issue is long-public, carries low exploitation probability, and affects only specific packaged deployments.

How an attack unfolds

A local attacker identifies an inactive D-Bus service, transmits a message that triggers an access-denied condition, and forces the daemon to deliver the error to the service itself, resulting in startup failure or observable side-channel behavior.

How to fix it

Upgrade D-Bus to 1.6.20, 1.8.4, or later; for the listed package, apply the update that ships the corrected D-Bus implementation.

How to confirm the fix worked

Verify the installed D-Bus version meets or exceeds 1.6.20 or 1.8.4; confirm that AccessDenied responses are delivered exclusively to clients and that affected services start without error under the same policy conditions.

Typical attack path

1. Locate an inactive D-Bus service on the local system
2. Craft and send a D-Bus message that the policy denies to the client
3. Observe the daemon forwarding the error to the service instead of the client
4. Trigger service initialization failure or gather side-channel data

How to detect it

Inspect system and D-Bus logs for repeated AccessDenied entries directed at service endpoints followed by service startup failures; correlate with process exit codes indicating initialization aborts.

What your security team should do

• Apply the available package update to reach the corrected D-Bus version
• Review local D-Bus policy files for overly permissive inactive services
• Include D-Bus version checks in routine vulnerability scanning