Hi folks, > what is the story there? I don't believe any of those MS reports > are actually (important) security issues,
The issue is basically that microsoft and/or their customers are allowing arbitrary code execution under a system user account (the same one that normally runs systemd-networkd). I can't speak for Debian, but other distros I've seen restrict who can "own" the systemd-networkd service name on the system dbus session to that user, so obviously if you allow that user to run arbitrary code then you're going to allow anything to bypass those restrictions. That's important in this context because networkd-dispatcher derives paths to scripts it runs based on the messages it receives on dbus for the systemd-networkd service. So if something else can "own" that name on the bus then it can (before the sanitation patch in the latest version) get networkd-dispatcher to run things located elsewhere. I should have been sanitizing input from dbus, which networkd-dispatcher does now. But again, in every other configuration I've seen, the user who is sending messages under that service is a dedicated system user who is only running systemd-networkd. > also why was this being disclosed publicly rather than responsibly? It was disclosed responsibly, as far as I understand the "responsible disclosure" process to be. They contacted me privately about a month ago about it, giving me enough time to come up with something to address it (I'm not paid to work on this :D) They also gave me a script to reproduce it shortly after contacting me, which (after a lot of effort) I was able to trigger it a couple of times in a VM running Arch Linux, but only after doing things that I shouldn't have been doing in the "real world" (e.g. sudo -u systemd-network ./foo) > The fixes for the alleged permission issue also only handles one > parent directory and classic permissions, but not any other > (grand)parents or ACLs. Ya, I'll admit that I'm not entirely sure if that particular change is all that useful... and I believe that it's up to distros to configure ACLs on the system. I would welcome any improvements to attempt to verify ACLs. So to recap: 1) if you don't re-use the systemd-network user (or whatever user your distro restricts the networkd dbus service name to) for running other things besides systemd-networkd, then this shouldn't be a problem. 2) If you do use the systemd-network user to run whatever, then networkd-dispatcher will now sanitize messages from dbus from the networkd dbus "service" (regardless of who/what has managed to own the name on the bus), so that it won't run things. This was shown by Microsoft to completely mitigate the issue. 3) system admins can still create symlinks to scripts outside of the config directories (which should be owned by root) the app searches, so it's still possible for system admins to footgun themselves, but networkd-dispatcher will at least *try* a little bit better now to prevent running things that are writeable by non-root users. -Clayton On Tue, 03 May 2022 14:12:14 +0200 Julian Andres Klode <j...@debian.org> wrote: > Hi Clayton (CC), > > what is the story there? I don't believe any of those MS reports > are actually (important) security issues, also why was this being > disclosed publicly rather than responsibly? > > The fixes for the alleged permission issue also only handles one > parent directory and classic permissions, but not any other > (grand)parents or ACLs. > > On Tue, May 03, 2022 at 01:21:12PM +0200, Julian Andres Klode wrote: > > On Thu, Apr 28, 2022 at 01:53:58PM +0200, Salvatore Bonaccorso wrote: > > > Source: networkd-dispatcher > > > Version: 2.1-2 > > > Severity: grave > > > Tags: security upstream > > > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > <t...@security.debian.org> > > > > > > Hi, > > > > > > The following vulnerabilities were published for networkd-dispatcher. > > > > > > CVE-2022-29799[0] and CVE-2022-29800[1]. > > > > > > If you fix the vulnerabilities please also make sure to include the > > > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > > > > I do not believe these are vulnerabilities. Microsoft claims a > > vulnerability exists if there is vulnerable code running under > > the systemd-network user, and claims that apt and epmd run under > > such user, but neither has communicated how those processes are > > vulnerable, nor why they would run under that user. > > > > It's likely that their tool is a confused deputy, running on a > > system with broken containers where container _apt and epmd > > users are mapped to the same UID as the host systemd-network > > (which still would not give them access to the bus), or it's > > a FUD smear campaign. > > > > Microsoft also claims that a vulnerability exists if scripts > > are writable by the user, however the directory is owned by > > root, so any scripts in there had to be written there by > > root. As such, that is a local admin choice to allow that > > user to run code as root. > > > > By the same argument, the code would have to check that any > > parent directory of the scripts is not writable by non-root > > users. > > > > The proposed fix also would not address this problem in the > > context of ACLs, as it only checks owner user and group, > > and mode, but not whether any ACLs are granted. Hence if that > > were really a bug, it's still not fixed. > > > > I can prepare a security update for this if people want it, > > but I do not believe in the existence of these bugs or that > > the fixes address them in a meaningful way. > > > > -- > > debian developer - deb.li/jak | jak-linux.org - free software dev > > ubuntu core developer i speak de, en > > > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en -Clayton pgp: https://craftyguy.net/key.txt
signature.asc
Description: PGP signature
