Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
Hi Julian, On Tue, May 03, 2022 at 06:22:37PM +0200, Julian Andres Klode wrote: > On Tue, May 03, 2022 at 08:47:56AM -0700, Clayton Craft wrote: > > 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 my understanding and hence why I asked them to publish a > correction within 4 business days that this is caused by local > misconfiguration and not a result of undisclosed security > vulnerabilities. > > > > > 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) > > So the way this usually goes is that distros also get notified, and > fixes are held back until a date (well hour really) coordinated by the > distros so everyone can release fixes at the same time, by way of > contacting the distros mailing list > (https://oss-security.openwall.org/wiki/mailing-lists/distros) or > individual email. > > Given that you are just working on this in your spare time and had not > had to deal with a CVE, I think MS should have at least helped ensure that > this is being communicated properly. So if I followed your both argumentation, then we can treat this within Debian as negligible issue, not impacting us. Julian, correct? If so we can simply close the bug with the version including those upstream comimits related and there is no necessity for a security update (and neither possibly a point release update, or maybe as hardening in the point release). I notice Ubuntu appears to have released a USN for this: https://ubuntu.com/security/notices/USN-5395-1 Regards, Salvatore
Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
On Tue, 03 May 2022 18:22:37 +0200 Julian Andres Klode wrote: > So the way this usually goes is that distros also get notified, and > fixes are held back until a date (well hour really) coordinated by the > distros so everyone can release fixes at the same time, by way of > contacting the distros mailing list > (https://oss-security.openwall.org/wiki/mailing-lists/distros) or > individual email. I see, thank you for explaining. This is my first CVE rodeo. > Given that you are just working on this in your spare time and had not > had to deal with a CVE, I think MS should have at least helped ensure that > this is being communicated properly. That makes sense. Let me know if there's anything I can do to help. -Clayton signature.asc Description: PGP signature
Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
On Tue, May 03, 2022 at 08:47:56AM -0700, Clayton Craft wrote: > 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 my understanding and hence why I asked them to publish a correction within 4 business days that this is caused by local misconfiguration and not a result of undisclosed security vulnerabilities. > > 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) So the way this usually goes is that distros also get notified, and fixes are held back until a date (well hour really) coordinated by the distros so everyone can release fixes at the same time, by way of contacting the distros mailing list (https://oss-security.openwall.org/wiki/mailing-lists/distros) or individual email. Given that you are just working on this in your spare time and had not had to deal with a CVE, I think MS should have at least helped ensure that this is being communicated properly. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
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 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 > > > > > > > > > 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
Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
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 > > > > > > 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 signature.asc Description: PGP signature
Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
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 > > > 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 signature.asc Description: PGP signature
Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
Source: networkd-dispatcher Version: 2.1-2 Severity: grave Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team 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. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2022-29799 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29799 [1] https://security-tracker.debian.org/tracker/CVE-2022-29800 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29800 [2] https://www.microsoft.com/security/blog/2022/04/26/microsoft-finds-new-elevation-of-privilege-linux-vulnerability-nimbuspwn/ Please adjust the affected versions in the BTS as needed. Regards, Salvatore
