Running the "embedded tests" through valgrind revealed that before this
commit, we would have been willing to read up to 3 bytes off the end of
a message if the message is truncated part way through a boolean. Any
practical allocator will round up allocations to the next 32-bit (or
larger) boundary, so in practice this will not leave the memory buffer
(and in particular did not crash during unit testing), but it could read
uninitialized contents.
On little-endian CPUs, an attacker might be able to use this to learn
whether up to 3 bytes of uninitialized memory in the dbus-daemon
were all-zero (their crafted message would be relayed) or not (their
connection would be disconnected for sending an invalid message). On
big-endian CPUs, an attacker might be able to use this to learn whether
up to 3 bytes were all-zeroes (relayed to a cooperating peer), 0-2
bytes of all-zeroes followed by 0x01 (relayed to a cooperating peer),
or something else (disconnected). This is not believed to be exploitable
to leak interesting information.
Fixes: 62e46533 "hardcode dbus_bool_t to 32 bits"
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107332
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit e93a775e68)
If re-initializing the string fails, it will be left in a state
where it has a length of 0 and a NULL buffer. That's valid to
"free", but not valid to pass to rmdir().
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107194
(cherry picked from commit 294e8b0b67)
If an implementation fails to listen, and a subsequent implementation
succeeds, then we would have leaked this. Detected by running
tests/loopback.c under valgrind.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107194
(cherry picked from commit b14a4517a8)
Using strncpy (buffer, str, strlen (str)) is a "code smell" that
might indicate a serious bug (it effectively turns strncpy into
strcpy), and gcc 8 now warns about it. In fact we avoided the bug
here, but it wasn't at all obvious.
We already checked that path_len is less than or equal to
_DBUS_MAX_SUN_PATH_LENGTH, which is 99, chosen to be strictly less
than the POSIX minimum sizeof(sun_path) >= 100, so we couldn't
actually be overflowing the available buffer.
The new static assertion in this commit matches a comment above the
definition of _DBUS_MAX_SUN_PATH_LENGTH: we define
_DBUS_MAX_SUN_PATH_LENGTH to 99, because POSIX says struct
sockaddr_un's sun_path member is at least 100 bytes (including space
for a \0 terminator). dbus will now fail to compile on
platforms that are non-POSIX-compliant in this way, except for Windows.
We zeroed the struct sockaddr_un before writing into it, so stopping
one byte short of the end of sun_path ensures that we get \0
termination.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107350
Reviewed-by: Thiago Macieira <thiago@kde.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit f429631365)
The foreach(list, (DBusForeachFunction) free, NULL) idiom seems too
entrenched to remove it from stable branches.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107349
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
For example, this can be the case in bubblewrap or Debian pbuilder after
unsharing the network namespace:
bwrap \
--bind / / \
--dev-bind /dev /dev \
--bind /dev/shm /dev/shm \
--bind /dev/pts /dev/pts \
--unshare-net \
${builddir}/test/test-loopback --tap
...
ok 1 /connect/tcp # SKIP Name resolution does not work here:
getaddrinfo("127.0.0.1", "0", {flags=ADDRCONFIG, family=INET,
socktype=STREAM, protocol=TCP}): Name or service not known
On some systems this can be circumvented by using nss_wrapper from
<https://cwrap.org/nss_wrapper.html>:
cat > hosts <<EOF
127.0.0.1 localhost
EOF
bwrap \
... \
env \
LD_PRELOAD=libnss_wrapper.so \
NSS_WRAPPER_HOSTS=$(pwd)/hosts \
${builddir}/test/test-loopback --tap
...
# listening at tcp:host=127.0.0.1,port=39219,family=ipv4,guid=...
but for systems where that does't work, we should be prepared to skip
the affected tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
(cherry picked from commit f1faafd59b)
Pathological autobuilder environments might not list localhost in
/etc/hosts.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
(cherry picked from commit 4cfc7de30d)
Minimal autobuilder environments don't always have working TCP,
so we may need to skip TCP tests. Make sure we test the equivalent
code paths via Unix sockets in those environments.
One notable exception is test/fdpass.c, which uses TCP as a transport
that is known not to be able to carry Unix fds; this needs to continue
to use TCP.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
(cherry picked from commit cb7dd5bfcc)
This expands test coverage, and lets us reuse the test for other
address schemes.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
(cherry picked from commit b19c9e2f26)
getaddrinfo and getnameinfo have their own error-handling convention
in which the library call returns either 0 or an EAI_* error code
unrelated to errno. If the error code is not EAI_SYSTEM, then
the value of errno is undefined (in particular it might be carried
over from a previous system call or library call). Introduce a
new helper function _dbus_error_from_gai() to handle this.
The equivalent code paths in Windows appear to be OK: the Windows
implementation of getaddrinfo() is documented to return a Winsock
error code, which we seem to be handling correctly.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106395
(cherry picked from commit 60cedd0cfd)
Otherwise, distcheck fails when mallard-ducktype is available.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 9391d769ae)
This might (?) have made sense behind a firewall in 2003; but now it's
2018, the typical threat model that we are defending against has
changed from "vandals want to feel proud of their l33t skills"
to "organised crime wants your money", and a "trusted" local LAN
probably contains an obsolete phone, tablet, games console or
Internet-of-Things-enabled toaster with remote root exploits.
This make network topologies that used to be acceptable look
increasingly irresponsible.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit d0a16b59a8)
This is the default, and blocks TCP-based attacks by making the
attacker fail to authenticate (while also preventing inadvisable
TCP-based configurations from working).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit aef4475939)
I'm far from convinced that this option should even *exist*, but it
should definitely be documented as a very bad thing.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit 5d36804867)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add a TODO comment as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit cf47380641)
With some fairly reasonable threat models (active or passive local
attacker able to eavesdrop on the network link, confidential
information being transferred via D-Bus), secure authentication is
insufficient to make this transport secure: it does not protect
confidentiality or integrity either.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit 2513f84db6)
The old version-1 format is deprecated and now produces warnings.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106186
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add the .devhelp2 file to .gitignore as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit fa92263920)
The tutorial is not necessarily a great entry point for the libdbus
documentation: it's infrequently updated, and we should probably have
the "If you use this low-level API directly, you're signing up for some
pain" message from the API reference show up in devhelp more immediately.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106186
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add longer commit message with rationale]
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit c84ac8b1ef)
Newer versions of yelp-build use this instead of a jQuery syntax
highlighter.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106171
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Also add it to .gitignore as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 49ad5b110f)
This gives us feature parity with the Autotools build system for this
particular area, and in particular means a system dbus-daemon built
with cmake can expand its fd limit.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105165
(cherry picked from commit a146724f2f)
Startup ordering was changed in #92832 to ensure that SELinux audit
messages could be sent. As a side effect, the raising of file descriptor
limits was moved to after the dropping of root privileges, resulting in
the limit change always failing.
Move the raise_file_descriptor_limit() call to ensure that it is called
before dropping root privileges.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105165
Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1529044
[smcv: Call raise_file_descriptor_limit() even if !context->user]
Reviewed-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 6e42964f5f)
Based on code contributed by Manish Narang. This is not included in the
automated test suite, because it isn't reliable on heavily-loaded
automatic test infrastructure like Travis-CI.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add the test to the CMake build system too, as requested]
[smcv: Convert into a manual test]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102839
(cherry picked from commit 0b1e292860)
This will be used in tests later in the branch.
Sadly we can't use GLIB_VERSION_2_44 unless we are willing to have a
hard dependency on GLib 2.44, which would force us to do all our
Travis-CI builds in Docker containers rather than in ye olde base
system, and that adds 50% to the time taken to do builds.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Rebase onto 1.13.x branch, fix minor conflicts]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
(cherry picked from commit d5742550ca)
The regular expression previously used here to select the second
comma-delimited argument won't work when we introduce an argument
containing a comma, which I need to do now. We can address this by
recognising Autoconf's quoting mechanism (which uses square
brackets).
This is not 100% right (it doesn't understand nested square brackets),
but it's good enough in practice.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Acked-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
(cherry picked from commit 83b439f7b4)
Tests that brute-force OOM code paths can be rather slow.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 5c91d85f3e)
DBusLoop isn't thread-safe, so we can't use it to test multi-threaded
situations.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102839
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit f127c8e110)
[smcv: Adjust for older codebase]
If one thread is blocking on a pending call, and another thread is
dispatching the connection, then we need them to agree on the value
of the completed flag by protecting all accesses with a lock. Reads
for this member seem to have the connection lock already, so it's
sufficient to make sure that the only write also happens under the
connection lock.
We already set the completed flag before calling the callback, so it
seems OK to stretch it to meaning that some thread has merely *taken
responsibility for* calling the callback.
The completed flag shares a bitfield with timeout_added, but that
flag is protected by the connection lock already.
Based on suggestions from Simon McVittie on
<https://bugs.freedesktop.org/show_bug.cgi?id=102839>.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102839
[smcv: Revert indentation changes; add commit message]
Reviewed-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit d3e03eb50e)
