Bugzilla – Bug 1221041
VUL-0: sddm-kcm6: shaky D-Bus service, potential sddm to root attack vectors
Last modified: 2024-03-06 10:15:01 UTC
+++ This bug was initially created as a clone of Bug #1217188 A dedicated bug to track the shortcomings in sddm-kcm6. From the original AUDIT bug: The shape of this service hasn't improved much over the last larger audit we did in bug 1145182. security aspects ---------------- - this service runs as root but at least in the `sync()` and `reset()` functions acts on behalf of the `sddm` service user. These functions place files into the `sddm` controlled home directory. A compromised `sddm` user might be able to use this for symlink attacks or DoS attacks. The helper should drop privileges to `sddm` for the functions that require this. - `openConfig()` likely follows symlinks in the path provided by the D-Bus client. This could allow to make arbitrary paths in the system world-readable. - `save()` removes a client provided "background path", remove logic that is also existing in some other spots. In this case it could be used to remove arbitrary paths in the system. - `installtheme()` accepts a path to a tar or zip archive and extracts it into the system theme dir. Since archives can contain relative pathnames it is no unlinkely that this could be used to create arbitrary files in arbitrary locations. minor findings -------------- - the `// initial check for sddm user; abort if user not present` is duplicate in the `sync()` and `reset()` functions. It should be moved into a small helper function. summary ------- we have two major problem classes here: - the helper service running as `root` operates in `sddm`s home directory, thus a compromised sddm user account could exploit this to achieve DoS, integrity violation or even privilege escalation. - the helper service accepts all kind of path names from D-Bus clients. All current actions need `auth_admin` authentication so it could be argued that they are equivalent to root. It still means that lowering these authentication requirements for any of these actions would be dangerous and create security issues. This would not be necessary in a cleanly designed helper. One major improvement would be not accepting path names but passed-on file descriptors from clients. But I'm not even sure if this is currently possible with the KAuth design. Or rather I'm pretty sure it's not possible. I will mention this in the kauth upstream ticket for kauth as well. Overall this kauth helper is in a bad shape security wise and should receive some improvements for the KDE6 release.