CVE-2014-3638 follow-up: improve data structures for pending replies
Submitted by Simon McVittie
Assigned to D-Bus Maintainers
Description
+++ This bug was initially created as a clone of Bug #81053 +++
Alban wrote: ----8<----
I have an issue with pending replies. It is related to the following limits:
- max_replies_per_connection; default: 1024*8; session=50000
- reply_timeout; default: -1 (disabled)
- max_connections_per_user=256
- max_replies total = max_replies_per_connection * max_connections_per_user = 25610248 per user
So a single user on the system bus could generate up to 2097152 pending replies that dbus-daemon has to track. All pending replies are tracked in the linked list "connections->pending_replies", see bus_connections_check_reply().
So every time a benign connection sends a D-Bus method, dbus-daemon has to iterate over this linked list. It is taking too much time and during that time, it uses the cpu and does not process other D-Bus connections.
While a malicious process creates as many pending requests as it can, I tested how long a benign method takes with the following command:
time dbus-send --system --print-reply
--dest=org.freedesktop.DBus /org/freedesktop/DBus
org.freedesktop.DBus.GetConnectionUnixProcessID
string::1.76
After enough pending replies being added in the linked list, the simple dbus-send takes more than _DBUS_DEFAULT_TIMEOUT_VALUE (25 seconds) and it fails.
The "time" command gave me once the following result: real 1m58.026s
The authentication steps are not included in the 25 seconds timeout, that's why "time" displays more than 25 seconds.
So while dbus-daemon is busy looping taking the cpu, D-Bus methods fail (depending on reply_timeout and applications' timeout) and authentication fails (depending on auth_timeout).
----8<----
The quick fix for this in 1.8.8 was to reduce the number of pending replies that are allowed, to the point where O(n) is not a big problem any more.
However, in 1.9 we should use better data structures.
Version: 1.5