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
