summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-02-04Imported Upstream version 1.8.16upstream/1.8.16upstreamSimon McVittie8-20/+62
2015-01-02Imported Upstream version 1.8.14upstream/1.8.14Simon McVittie9-19/+214
2014-11-24Imported Upstream version 1.8.12upstream/1.8.12Simon McVittie9-19/+80
2014-11-06Imported Upstream version 1.8.10upstream/1.8.10Simon McVittie11-65/+260
2014-11-06Embargoed security release for MondaySimon McVittie2-4/+11
2014-11-06CVE-2014-7824: set fd rlimit to 64k for the system dbus-daemonSimon McVittie6-43/+227
This ensures that our rlimit is actually high enough to avoid the denial of service described in CVE-2014-3636 part A. CVE-2014-7824 has been allocated for this incomplete fix. Restore the original rlimit for activated services, to avoid them getting undesired higher limits. (Thanks to Alban Crequy for various adjustments which have been included in this commit.) Bug: https://bugs.freedesktop.org/show_bug.cgi?id=85105 Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
2014-09-161.8.9Simon McVittie2-1/+6
2014-09-15Imported Upstream version 1.8.8upstream/1.8.8Simon McVittie41-299/+697
2014-09-15Prepare 1.8.8 (embargoed until tomorrow)dbus-1.8.8Simon McVittie2-4/+42
2014-09-15_dbus_read_socket_with_unix_fds: do not accept extra fds in cmsg paddingSimon McVittie1-6/+43
This addresses CVE-2014-3635. If (*n_fds * sizeof (int) % sizeof (size_t)) is nonzero, then CMSG_SPACE (*n_fds * sizeof (int)) > CMSG_LEN (*n_fds * sizeof (int) because the SPACE includes padding to a size_t boundary, whereas the LEN does not. We have to allocate the SPACE. Previously, we told the kernel that the buffer size we wanted was the SPACE, not the LEN, which meant it was free to fill the padding with additional fds: on a 64-bit platform with 32-bit int, that's one extra fd, if *n_fds happens to be odd. This meant that a malicious sender could send exactly 1 fd too many, which would make us fail an assertion if enabled, or overrun a buffer by 1 fd otherwise. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83622 Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
2014-09-15Add _DBUS_GNUC_UNUSED, and use it in _DBUS_STATIC_ASSERTSimon McVittie2-1/+4
This means we can use _DBUS_STATIC_ASSERT at non-global scope without tripping -Wunused-local-typedefs. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83767 Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk> (cherry picked from commit 0e3d08d45cb9a9ceb2c077875eeb38306dad37b8)
2014-09-15bus: enforce pending_fd_timeoutAlban Crequy1-0/+71
This is one of four commits needed to address CVE-2014-3637. The bus uses _dbus_connection_set_pending_fds_function and _dbus_connection_get_pending_fds_count to be notified when there are pending file descriptors. A timeout per connection is armed and disarmed when the file descriptor list is used and emptied. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80559 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2014-09-15DBusConnection: implements _dbus_connection_set_pending_fds_functionAlban Crequy7-0/+70
This is one of four commits needed to address CVE-2014-3637. This will allow the bus to be notified whenever a file descriptor is added or removed from a DBusConnection's DBusMessageLoader. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80559 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2014-09-15DBusConnection: implements _dbus_connection_get_pending_fds_countAlban Crequy6-0/+40
This is one of four commits needed to address CVE-2014-3637. This will allow the bus to know whether there are pending file descriptors in a DBusConnection's DBusMessageLoader. https://bugs.freedesktop.org/show_bug.cgi?id=80559 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk> [fix compilation on platforms that do not HAVE_UNIX_FD_PASSING -smcv] Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2014-09-15config: add new limit: pending_fd_timeoutAlban Crequy5-0/+25
This is one of four commits needed to address CVE-2014-3637. When a file descriptor is passed to dbus-daemon, the associated D-Bus message might not be fully sent to dbus-daemon yet. Dbus-daemon keeps the file descriptor in the DBusMessageLoader of the connection, waiting for the rest of the message. If the client stops sending the remaining bytes, dbus-daemon will wait forever and keep that file descriptor. This patch adds pending_fd_timeout (milliseconds) in the configuration to disconnect a connection after a timeout when a file descriptor was sent but not the remaining message. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80559 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2014-09-15Stop listening on DBusServer sockets when reaching max_incomplete_connectionsAlban Crequy8-42/+88
This addresses the parts of CVE-2014-3639 not already addressed by reducing the default authentication timeout. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80851 Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80919 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2014-09-15config: change default auth_timeout to 5 secondsAlban Crequy1-1/+1
This partially addresses CVE-2014-3639. This will change the default on the system bus where the limit <limit name="auth_timeout">...</limit> is not specified. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80919 Reviewed-by: Thiago Macieira <thiago@kde.org> Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2014-09-15config: change DEFAULT_MESSAGE_UNIX_FDS to 16Simon McVittie6-18/+11
This addresses CVE-2014-3636. Based on a patch by Alban Crequy. Now that it's the same on all platforms, there's little point in it being set by configure/cmake. This change fixes two distinct denials of service: fd.o#82820, part A ------------------ Before this patch, the system bus had the following default configuration: - max_connections_per_user: 256 - DBUS_DEFAULT_MESSAGE_UNIX_FDS: usually 1024 (or 256 on QNX, see fd.o#61176) as defined by configure.ac - max_incoming_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS*4 = usually 4096 - max_outgoing_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS*4 = usually 4096 - max_message_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS = usually 1024 This means that a single user could create 256 connections and transmit 256*4096 = 1048576 file descriptors. The file descriptors stay attached to the dbus-daemon process while they are in the message loader, in the outgoing queue or waiting to be dispatched before D-Bus activation. dbus-daemon is usually limited to 65536 file descriptors (ulimit -n). If the limit is reached and dbus-daemon needs to receive a message with a file descriptor attached, this is signalled by recvfrom with the flag MSG_CTRUNC. Dbus-daemon cannot recover from that error because the kernel does not have any API to retrieve a file descriptor which has been discarded with MSG_CTRUNC. Therefore, it closes the connection of the sender. This is not necessarily the connection which generated the most file descriptors so it can lead to denial-of-service attacks. In order to prevent DoS issues, this patch reduces DEFAULT_MESSAGE_UNIX_FDS to 16: max_connections_per_user * max_incoming_unix_fds = 256 * 64 = 16384 This is less than the usual "ulimit -n" (65536) with a good margin to accomodate the other sources of file descriptors (stdin/stdout/stderr, listening sockets, message loader, etc.). Distributors on non-Linux may need to configure a smaller limit in system.conf, if their limit on the number of fds is smaller than Linux's. fd.o#82820, part B ------------------ On Linux, it's not possible to send more than 253 fds in a single sendmsg() call: sendmsg() would return -EINVAL. #define SCM_MAX_FD 253 SCM_MAX_FD changed value during Linux history: - it used to be (OPEN_MAX-1) - commit c09edd6eb (Jul 2007) changed it to 255 - commit bba14de98 (Nov 2010) changed it to 253 Libdbus always sends all of a message's fds, and the beginning of the message itself, in a single sendmsg() call. Combining these two, a malicious sender could split a message across two or more sendmsg() calls to construct a composite message with 254 or more fds. When dbus-daemon attempted to relay that message to its recipient in a single sendmsg() call, it would receive EINVAL, interpret that as a fatal socket error and disconnect the recipient, resulting in denial of service. This is fixed by keeping max_message_unix_fds <= SCM_MAX_FD. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=82820 Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
2014-09-15system bus limit: use max_replies_per_connection=128 by defaultAlban Crequy1-1/+1
This addresses CVE-2014-3638. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=81053 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2014-09-15NEWS for 1.8Simon McVittie1-0/+4
2014-09-15On Linux, call prctl to disable core dumpsSimon McVittie2-1/+21
Whenever I forget to turn off corekeeper, the regression tests take ages to record all test-segfault's crashes. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83772 Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
2014-09-12NEWS for 1.8.xSimon McVittie1-0/+7
2014-09-12enable build support without systemd compatibility librariesUmut Tezduyar Lindskog1-4/+7
systemd 209 merged all the libraries to libsystemd. Old libraries can still be enabled with --enable-compat-libs switch in systemd but this increases the binary size. Implement a fallback library check in case compat libraries dont exist. [Fixed underquoting; switched priority so we try libsystemd first -smcv] Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2014-09-07Fix windows doc for running tests.Ralf Habacker1-4/+9
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41252 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2014-09-05NEWS for 1.8Simon McVittie1-1/+4
2014-09-04Stats: fix compilation issueAlban Crequy1-1/+3
Bug-Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=507232 Bug: https://bugs.freedesktop.org/show_bug.cgi?id=81043 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2014-07-02start 1.8.7Simon McVittie2-1/+6
2014-06-30Imported Upstream version 1.8.6upstream/1.8.6Simon McVittie8-18/+89
2014-06-30Prepare 1.8.6 in advancedbus-1.8.6Simon McVittie2-4/+19
2014-06-30Handle ETOOMANYREFS when sending recursive fds (SCM_RIGHTS)Alban Crequy3-1/+48
Since Linux commit 25888e (from 2.6.37-rc4, Nov 2010), sendmsg() on Unix sockets returns -1 errno=ETOOMANYREFS ("Too many references: cannot splice") when the passfd mechanism (SCM_RIGHTS) is "abusively" used recursively by applications. A malicious client could use this to force a victim system service to be disconnected from the system bus; the victim would likely respond by exiting. This is a denial of service (fd.o #80163, CVE-2014-3532). This patch silently drops the D-Bus message on ETOOMANYREFS and does not close the connection. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80163 Reviewed-by: Thiago Macieira <thiago@kde.org> [altered commit message to explain DoS significance -smcv] Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2014-06-30If loader contains two messages with fds, don't corrupt the secondSimon McVittie1-1/+1
There were two bugs here: we would previously overwrite the unused fds with the already-used fds instead of the other way round, and we would copy n bytes where we should have copied n ints. Additionally, sending crafted messages in a chosen sequence to a victim system service could cause an invalid file descriptor to be present when dbus-daemon tries to forward one of those crafted messages to the victim, causing sendmsg() to fail with EBADF, which resulted in disconnecting the victim service, which would likely respond to that by exiting. This is a denial of service (fd.o #80469, CVE-2014-3533). Bug: https://bugs.freedesktop.org/show_bug.cgi?id=79694 Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80469 Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
2014-06-11NEWSSimon McVittie1-1/+5
2014-06-11dbus-launch: kill bus if we can't attach to a session when requestedРоман Донченко1-1/+1
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=74698 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2014-06-10reset versionSimon McVittie2-1/+6
2014-06-05Imported Upstream version 1.8.4upstream/1.8.4Simon McVittie6-26/+50
2014-06-05Prepare embargoed security releasedbus-1.8.4Simon McVittie2-3/+11
2014-06-05CVE-2014-3477: deliver activation errors correctly, fixing Denial of ServiceAlban Crequy3-11/+24
How it should work: When a D-Bus message activates a service, LSMs (SELinux or AppArmor) check whether the message can be delivered after the service has been activated. The service is considered activated when its well-known name is requested with org.freedesktop.DBus.RequestName. When the message delivery is denied, the service stays activated but should not receive the activating message (the message which triggered the activation). dbus-daemon is supposed to drop the activating message and reply to the sender with a D-Bus error message. However, it does not work as expected: 1. The error message is delivered to the service instead of being delivered to the sender. As an example, the error message could be something like: An SELinux policy prevents this sender from sending this message to this recipient, [...] member="MaliciousMethod" If the sender and the service are malicious confederates and agree on a protocol to insert information in the member name, the sender can leak information to the service, even though the LSM attempted to block the communication between the sender and the service. 2. The error message is delivered as a reply to the RequestName call from service. It means the activated service will believe it cannot request the name and might exit. The sender could activate the service frequently and systemd will give up activating it. Thus the denial of service. The following changes fix the bug: - bus_activation_send_pending_auto_activation_messages() only returns an error in case of OOM. The prototype is changed to return TRUE, or FALSE on OOM (and its only caller sets the OOM error). - When a client is not allowed to talk to the service, a D-Bus error message is pre-allocated to be delivered to the client as part of the transaction. The error is not propagated to the caller so RequestName will not fail (except on OOM). [fixed a misleading comment -smcv] Bug: https://bugs.freedesktop.org/show_bug.cgi?id=78979 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Colin Walters <walters@verbum.org>
2014-04-30development versionSimon McVittie2-1/+4
2014-04-30Imported Upstream version 1.8.2upstream/1.8.2Simon McVittie17-30/+148
2014-04-301.8.2dbus-1.8.2Simon McVittie2-3/+8
2014-04-30Handle 0x0d0a EOLs in spawn_dbus_daemon()Руслан Ижбулатов2-0/+4
On W32 dbus daemon will print output in text mode, with 0x0d0a EOLs instead of just 0x0a. Be able to handle that. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75863 Reviewed-by: Simon McVittie
2014-04-30NEWSSimon McVittie1-0/+3
2014-04-30Avoid killing all available processes if an X error arrives early onРоман Донченко1-1/+7
The timeline of events in dbus-launch's main process goes something like this: * do initial X calls [1] * do some other stuff * fork (child process starts doing some other stuff) * return "intermediate parent" pid from fork() * obtain bus daemon pid from bus_pid_to_launcher_pipe [2] * do things that might include X11 calls or killing the dbus-daemon Meanwhile, the "babysitter" child goes like this: * return 0 from fork() [3] * obtain bus daemon pid from parent process via bus_pid_to_babysitter_pipe [4] * do things that might include X11 calls or killing the bus daemon Before [1] or [3], the right thing to do about an X error is to just exit. The current implementation called kill(-1) first, which is undesirable: it kills unrelated processes. With this change, we just exit. After [2] or [4], the right thing to do is to kill the dbus-daemon, and that's what the existing code did. Between [1] and [2], or between [3] and [4], there is no correct thing that we can do immediately: we would have to wait for the end of the "critical section", *then* kill the dbus-daemon. This has not yet been implemented, so this patch relies for its correctness on the fact that there are no libX11 calls between those points, so we cannot receive an X error between them. dbus-launch deserves more comments, or a reimplementation that is easier to understand, but this change is certainly better than nothing. [Commit message added, summarizing reviewers' comments -smcv] Bug: https://bugs.freedesktop.org/show_bug.cgi?id=74698 Reviewed-by: Simon McVittie Reviewed-by: Thiago Macieira
2014-04-28NEWS for 1.8Simon McVittie1-0/+6
2014-04-28Add "Documentation=man:dbus-daemon(1)" line to systemd serviceCameron Norman1-0/+1
Enhances usability under systemd by making the documentation available with systemctl status or systemctl help. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=77447 Reviewed-by: Simon McVittie
2014-04-28Try to read /etc/machine-id before inventing a new /var/lib/dbus/machine-idSimon McVittie1-2/+21
It's least confusing if the two files have the same contents. systemd already knows how to pick up our /var/lib/dbus/machine-id if it exists and /etc/machine-id doesn't, but the converse is not currently true. We should make it true, so that it doesn't matter what order systemd-machine-id-setup and "dbus-uuidgen --ensure" were invoked in. In Debian, systemd currently Recommends dbus, so "dbus-uuidgen --ensure" will *usually* - but not always! - run first, and the two files will match. However, if you install systemd without dbus, and then install dbus later, there will be a mismatch. With this change, it doesn't matter which one is installed first: whichever one happens to come first, it will generate the machine ID, and then the other one will copy it. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=77941 Reviewed-by: Lennart Poettering
2014-04-28_dbus_write_uuid_file: factor out function to write a known UUIDSimon McVittie2-7/+18
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=77941 Reviewed-by: Lennart Poettering
2014-03-13Update email-address for David Zeuthen.David Zeuthen1-2/+1
I no longer have the email address davidz@redhat.com so update it to my current address. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75288
2014-03-06Update .gitignore filesLukasz Skalski2-0/+7
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75833 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2014-03-03NEWS for dbus-1.8Simon McVittie1-1/+10
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-21 07:03:18 +0000