|Summary:||followup for CVE-2014-3532: messages with abusive recursion are silently dropped|
|Product:||dbus||Reporter:||Simon McVittie <smcv>|
|Component:||core||Assignee:||D-Bus Maintainers <dbus>|
|Status:||RESOLVED MOVED||QA Contact:||D-Bus Maintainers <dbus>|
|Priority:||low||CC:||alban.crequy, kay, lennart, msniko14, thiago, walters|
|i915 platform:||i915 features:|
|Bug Depends on:||80163|
Description Simon McVittie 2014-07-02 16:12:43 UTC
+++ This bug was initially created as a clone of Bug #80163 +++ > An original fd can be inserted in the ancillary data of a message. > While that message is waiting in the socket queue of the other end, > the fd of the other end can itself be inserted in the ancillary data > of another message. [Recent Linux] considers that doing that > recursively more than 4 times is abusive: > #define MAX_RECURSION_LEVEL 4 ... > dbus-daemon has no way to check whether a > received fd will trigger a ETOOMANYREFS when forwarding the D-Bus > message to recipients. Moreover, the ability to forward the file > descriptor changes asynchronously when other processes append messages > on the fd's delivery queue. Since 1.8.6, if sendmsg() fails with ETOOMANYREFS, dbus-daemon silently drops the message on the floor to avoid DoS. It would be nice if it sent back an error reply, if the message was one that expects a reply (i.e. a method call). Alban started trying to implement that, but ran into considerable practical difficulties, and we agreed that the patch he proposed was too big for a security fix. If someone wants to implement the rest of the ideal solution, i.e. sending back an error reply, now is the time. Alternatively, logging the bad message to syslog might be a reasonable thing to do. This is, again, complicated by the fact that the error condition is hit in generic libdbus code, and we would only want dbus-daemon to syslog it.
Comment 1 GitLab Migration User 2018-10-12 21:18:03 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/104.