Bug#930376: gvfsd GetConnection() missing authorization check
Tags: security fixed-upstream patch
While looking for services that might be vulnerable to CVE-2019-12749
or a similar vulnerability, I noticed that gvfsd has a mechanism to open
a private D-Bus server socket, and does not configure an authorization
check for clients connecting to that socket. An attacker who learns the
abstract socket address from netstat(8) or similar could connect to it
and issue D-Bus method calls.
Mitigation: the attacker would have to win a race with the user owning
gvfsd, who is probably also trying to connect to the same socket. gvfsd
closes the socket after it has accepted one connection.
I have requested a CVE ID from MITRE but not received one yet.
For buster/sid this has been fixed in gvfs 1.38.1-5.
For experimental this has been fixed in gvfs 1.40.1-2.
I do not have a tested patch for stretch or jessie, but the same change
would probably work as-is.
It would probably be a good idea to also backport
for additional hardening. This forces authentication to use the
simple, robust EXTERNAL (credentials-passing) mechanism, disabling
DBUS_COOKIE_SHA1, which is somewhat fragile and seems more likely to
contain unknown vulnerabilities.