Bug 1148925 - (CVE-2019-15718) VUL-0: CVE-2019-15718: systemd: Missing access controls on systemd-resolved's D-Bus interface
(CVE-2019-15718)
VUL-0: CVE-2019-15718: systemd: Missing access controls on systemd-resolved's...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security
Current
Other Other
: P3 - Medium : Normal (vote)
: ---
Assigned To: Security Team bot
E-mail List
https://smash.suse.de/issue/241497/
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-08-30 07:11 UTC by Alexandros Toptsoglou
Modified: 2019-10-10 05:48 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Alexandros Toptsoglou 2019-08-30 07:12:22 UTC
Created attachment 816352 [details]
0001-shared-but-util-drop-trusted-annotation-from-bus_ope.patch
Comment 4 Marcus Meissner 2019-08-30 12:12:38 UTC
I think we so far did not ship resolved on SLES.
Not sure about Leap and Factory.
Comment 8 Franck Bui 2019-09-03 12:17:23 UTC
(In reply to Alexandros Toptsoglou from comment #0)
> manager_connect_bus() in src/resolve/resolved-bus.c opens a connection
> to the system bus using the
> bus_open_system_watch_bind_with_description() helper function, which is
> defined in src/shared/bus-util.c.

It looks like bus_open_system_watch_bind_with_description() has been introduced in v237 so only Factory should be affected.
Comment 9 Alexandros Toptsoglou 2019-09-04 06:35:54 UTC
now public via oss-sec 

Hi,

Nadav Markus from Palo Alto Networks discovered that systemd-resolved
does not enforce appropriate access controls on its D-Bus interface and
allows unprivileged users to execute methods that are meant to be
available only to privileged users. This can be exploited by local users
to modify the system's DNS resolver settings.

Details of the issue follow:

-----

manager_connect_bus() in src/resolve/resolved-bus.c opens a connection
to the system bus using the
bus_open_system_watch_bind_with_description() helper function, which is
defined in src/shared/bus-util.c.

This helper function calls sd_bus_set_trusted(). This has the effect of
disabling access controls, even for members that are defined without the
SD_BUS_VTABLE_UNPRIVILEGED flag - the absence of which should deny
access from unprivileged clients. See check_access() in
src/libsystemd/sd-bus/bus-objects.c:

static int check_access(sd_bus *bus, sd_bus_message *m, struct
vtable_member *c, sd_bus_error *error) {
        uint64_t cap;
        int r;

        assert(bus);
        assert(m);
        assert(c);

        /* If the entire bus is trusted let's grant access */
        if (bus->trusted)
                return 0;

        /* If the member is marked UNPRIVILEGED let's grant access */
        if (c->vtable->flags & SD_BUS_VTABLE_UNPRIVILEGED)
                return 0;
        ...

timesyncd and networkd both use the same helper function to connect to
the system bus, but both of these are unaffected by this bug. In
timesyncd's case, it only exposes some read-only properties and these
don't have access controls. In networkd's case, all methods are
annotated with SD_BUS_VTABLE_UNPRIVILEGED and it uses policykit for
enforcing access controls.

-----

The complete fix for this issue can be found at
https://github.com/systemd/systemd/pull/13457 and is in the systemd v243
release, although
https://github.com/systemd/systemd/pull/13457/commits/35e528018f315798d3bffcb592b32a0d8f5162bd
on its own is sufficient to address the vulnerability.

Many thanks
- Chris
Comment 10 Franck Bui 2019-10-09 15:06:21 UTC
v243 has finally been released in both Factory and Tumbleweed.

It contains the fix (commit 35e528018f315798d3bffcb592b32a0d8f5162bd) so we should be fine now.

Re-assigning to the security team.
Comment 11 Marcus Meissner 2019-10-10 05:48:19 UTC
fixed