Microsoft Finds Linux Desktop Flaw That Gives Root To Untrusted Users (arstechnica.com) 75
An anonymous reader quotes a report from Ars Technica: Vulnerabilities recently discovered by Microsoft make it easy for people with a toehold on many Linux desktop systems to quickly gain root system rights -- the latest elevation of privileges flaw to come to light in the open source OS. [...] Nimbuspwn, as Microsoft has named the EoP threat, is two vulnerabilities that reside in the networkd-dispatcher, a component in many Linux distributions that dispatch network status changes and can run various scripts to respond to a new status. When a machine boots, networkd-dispatcher runs as root. [...] A hacker with minimal access to a vulnerable desktop can chain together exploits for these vulnerabilities that give full root access. [The step-by-step exploit flow can be found in the article. The researcher also was able to gain persistent root access using the exploit flow to create a backdoor.]
The proof-of-concept exploit works only when it can use the "org.freedesktop.network1" bus name. The researcher found several environments where this happens, including Linux Mint, in which the systemd-networkd by default doesn't own the org.freedodesktop.network1 bus name at boot. The researcher also found several processes that run as the systemd-network user, which is permitted to use the bus name required to run arbitrary code from world-writable locations. The vulnerable processes include several gpgv plugins, which are launched when apt-get installs or upgrades, and the Erlang Port Mapper Daemon, which allows running arbitrary code under some scenarios. The vulnerability has been patched, although it's unclear which version of Linux the patch is in.
The proof-of-concept exploit works only when it can use the "org.freedesktop.network1" bus name. The researcher found several environments where this happens, including Linux Mint, in which the systemd-networkd by default doesn't own the org.freedodesktop.network1 bus name at boot. The researcher also found several processes that run as the systemd-network user, which is permitted to use the bus name required to run arbitrary code from world-writable locations. The vulnerable processes include several gpgv plugins, which are launched when apt-get installs or upgrades, and the Erlang Port Mapper Daemon, which allows running arbitrary code under some scenarios. The vulnerability has been patched, although it's unclear which version of Linux the patch is in.
What a bunch of stupidities... (Score:2)
Seriously, a bug in the network manager is a "desktop flaw"?
I mean, I can find thousand of bugs in 3rd party network managers in Windows and I wouldn't ever call it a "desktop flaw".
Re:What a bunch of stupidities... (Score:5, Insightful)
Except this piece of software is now essentially bundled and forced on most Linux users because most of the major distros jumped on the systemd bandwagon. And at that point, it makes it a Linux flaw.
Re: (Score:2, Informative)
Funny, I don't get the impression that RedHat, CentOS or Fedora will be vulnerable to this. Come to think of it, I'll bet SuSE distributions are fairly immune. Arguably, the two biggest Linux distributions don't use apt, meaning the two biggest Linux distributions are not compromised. It's not a Linux flaw
Re: (Score:2)
Any process that can run as the user systemd-network is vulnerable. Doesn't have to be apt.
Re: (Score:2)
Re: (Score:2)
My main Debian system has no systemd in it, so I have the suspicion that I'm immune too.
Re: (Score:3)
Not that prevalent. (Score:2)
All the distributions you mention could be potentially affected as they do use networkd.
Correction: All the distributions mentioned could be potentially affected as they do feature a package networkd (e.g.: in openSUSE that would be systemd-network) but it's not the default system used to connect to networks (e.g.: nearly all modern desktop distributions default to NetworkManager instead for laptops and desktops to have more configurable options (VPNs, Wifi, etc.)).
You're most likely to find systed-networkd found on VMs and containers, i.e.: system with simpler networking use-cases that requir
Re:What a bunch of stupidities... (Score:5, Insightful)
No systemd or dbus here. I run Debian. Should Debian ever stop working right without these two bad ideas, I will move to Gentoo. Already have a first test-server with it running. Just say no to bad tech.
Re:What a bunch of stupidities... (Score:4, Informative)
I use gentoo on my home desktop. Its a major pain to update it, and you have to keep doing it, otherwise you have even bigger pains.
Re: (Score:2)
I have automated that. It is the one thing I want to see how it goes longer-term. Headless server though.
Re:What a bunch of stupidities... (Score:5, Informative)
Except this piece of software is now essentially bundled and forced on most Linux users because most of the major distros jumped on the systemd bandwagon.
The software with the vulnerability, networkd-dispatcher [gitlab.com], is not part of systemd. Its a plugin that some distros have included.
This is not a Linux flaw. Nor is it a systemd flaw.
Re:What a bunch of stupidities... (Score:5, Funny)
How dare you get in the way of a baseless systemd bashing. Take your facts elsewhere, you're not welcome here.
Re: (Score:2)
Since systemd allows a plugin to compromise the system, of course it's a systemd flaw.
Re: (Score:2)
The systemd package (and all other packages) in Debian has no file named "networkd-dispatcher". I thought Microsoft used Debian? How did they even find this vulnerability?
Re: (Score:2)
aw rats, there is a networkd-dispatcher package that I overlooked :( Anyway, all networkd crap needs to be killed with fire.
Re: (Score:2, Flamebait)
Re:What a bunch of stupidities... (Score:4, Funny)
me: "ahhh now that's the stuff."
Re: (Score:1)
Professional gaslighting at its finest. Notice how they even came up with a catchy brand name for the exploit before announcing it.
System works as intended. (Score:2, Interesting)
Still, kudos to the ladies and gentlemen at Microsoft. It must have been a difficult decision to report this vulnerability instead of helping it appear in the wild (hey, not saying M$ would do this, but if I were M$, I'd be tempted).
Re: (Score:2)
Re: (Score:1)
What comes after embrace...?
Why, "Extend" and then "Extinguish", of course!
Re: (Score:2)
Perhaps Microsoft's aim is most Debian installs to run under Windows?
Re: (Score:2)
Perhaps Microsoft's aim is most Debian installs to run under Windows?
Riiight. . .
Re: (Score:2)
Microsoft may want to extinguish desktop Linux, but their biggest growth area is in cloud computing - where they've pretty much conceded Linux is the way to go. If only to lure AWS linux deployments over to their platform. WSL is, paradoxically, an attempt to prevent developers from using desktop Linux for their work by including a server-only linux distro in the Windows desktop. Nobody but a developer would ever use it - and that crowd could easily (and probably did) dual-boot into Linux to do their wor
Re: (Score:2)
Microsoft may want to extinguish desktop Linux, but their biggest growth area is in cloud computing - where they've pretty much conceded Linux is the way to go. If only to lure AWS linux deployments over to their platform. WSL is, paradoxically, an attempt to prevent developers from using desktop Linux for their work by including a server-only linux distro in the Windows desktop. Nobody but a developer would ever use it - and that crowd could easily (and probably did) dual-boot into Linux to do their work without WSL. So this thing is hardly an act of Microsoft love for linux on the desktop.
Interesting!
I had no idea it was Server-only. How does MS even do that?
Isn't that an Anti-Trust issue? ;-)
Re: (Score:2)
Embrace Extend Extinguish! M$ is evil!!
Microsoft doesn't support {thing}:
Vendor Lock-in! M$ is evil!
Re: (Score:1)
Microsoft supports {thing}:
Embrace Extend Extinguish! M$ is evil!!
Microsoft doesn't support {thing}:
Vendor Lock-in! M$ is evil!
Now you're getting it!
Re: System works as intended. (Score:1)
Re: (Score:3)
(hey, not saying M$ would do this, but if I were M$, I'd be tempted).
Give how much money M$ makes of Linux, a system it is not in any way in direct competition with anymore, the fact you are even tempted makes you incredibly stupid.
Or maybe you just woke from a 20 year coma and didn't realise it's not the early 00s anymore and the dynamics in IT world have fundamentally changed, in which case I unreservedly apologise for my insult.
distros (Score:1)
yet another reason to dislike systmed (Score:5, Interesting)
Re:yet another reason to dislike systmed (Score:5, Interesting)
but without prejudice what is systemd supposed to bring to the part[y]?
I'm no systemd expert, so feel free to correct me if I get something wrong. The main benefit of systemd is dynamic and intelligent handling of system resources. For example, USB device connection and disconnection detection was horribly unreliable pre-systemd. The same was true of network interfaces. For me, this was a night and day improvement. What rarely and barely worked pre-systemd suddenly worked reliably all the time.
I was also resistant to change, but systemd has proven itself to be functionally superior to SysV init continuously and dramatically over the years.
Re: (Score:3, Interesting)
I'm no systemd expert, so feel free to correct me if I get something wrong.
I'm no systemd expert because I'm a Gentoo user that didn't feel the need to switch.
For example, USB device connection and disconnection detection was horribly unreliable pre-systemd.
I can't think of many, if any times, I had difficultly with a fully functioning usb device in regards to connections and disconnections that would be fixed by systemd. Mice, keyboard, thumb drives, all fine. I do know that at some point I stopped mounting usb drives by hand and for some time now, I've been mount and unmounting drives with KDE's file manager Dolphin or from the popup that appears in the notifications area.
The same was true of network interfaces. For me, this was a night and day improvement.
I
Re: (Score:2)
What is the share of Gentoo users between other linux users? (asking because I only know Gentoo users here on /. ...)
Re: (Score:2)
IIRC, most of the problems with USB device connections were fixed before systemd appeared. What was fixed about the same time as it appeared was controlling the order in which separately connected SCSI disks were mounted (and the names that the system knew them by).
Re: (Score:1)
Systemd has proven itself to be an unmitigated piece of dogshit over the years and this is just one more bit of evidence on a mountain already accumulated. You are fucking high. Nearly everything you wrote is completely the opposite. Networking, USB, security, and the ACTUAL STARTUP procedure is much more complex, failure prone, and insecure. The track record for this garbage speaks volumes for itself. Go ahead and compare 30 years worth of CVE data for 'init' with systemd. I'll wait.
Re: (Score:3)
Seriously, can someone please explain to me why going to systemd benefits the distro?
I admit that I have been doing *NIX so long, and am resistant to change without a clear benefit, but without prejudice what is systemd supposed to bring to the part?
Yeah, too bad Linux Apple Haters couldn't just accept Apple's gift of launchd (offered under the Apache 2.0 License since 2006). It doesn't seem to have these vulnerabilities, and has been in constant use in OS X/macOS since 2004 (starting with OS X 10.4 Tiger).
But Lance's crappy version has been the bane of Linux for well over a decade at this point.
Re:yet another reason to dislike systmed (Score:5, Informative)
It might have been OK at some point, but as of current (12.3.1), it's a mix of deprecated and broken interfaces, undefined behavior, and undocumented basic operation.
Fuck launchd.
systemd is 1000% better. Systemd itself isn't so bad as long as you limit the level at which it's integrated, which is more the fault of distributions.
People who think launchd is cool are people who have probably never actually used it, and rely on the basics of just copying and pasting some obscure commands to enable a service that Apple already setup for you.
These days it's cool to replace the syslog with systemd (or have systemd forward to an external syslog, making you think it hasn't taken it over, until it breaks), DNS resolution, and network control, and at that point it becomes pretty fucking problematic, because slight misbehavior in the core of systemd causes the entire system to become an undefined (in the C sense of the word) mess of random breakage that makes no sense.
Finally, this exploit isn't in systemd. It's in a third-party tool that uses systemd. Systemd is not at fault here.
Re: (Score:2)
First, I defer to your knowledge of systemd. You say it is better; ok.
But how in the hell can launchd be as bad as you describe? Apple's OSes depend on it for a lot of things. It simply cannot be that broken!
Re: (Score:2)
Apple's launchd works if you use it in exactly the right way and don't try to do anything even slightly out of the ordinary. It really isn't flexible enough to be a great choice. Sun's smf had the same problem of only being useful in very narrow use cases.
Re: (Score:2)
First, I defer to your knowledge of systemd. You say it is better; ok.
Note: I'm not a "fan" of systemd. I do like its basic init shit. Unit files really aren't bad, and once you get a grapple of units and targets, you can make the thing work for you in really good ways. The way systemd is being integrated into modern distros is a fucking joke, though. Distributions are replacing better software, with better maintainers, with systemd just for ease of package maintenance, and that sucks.
But how in the hell can launchd be as bad as you describe? Apple's OSes depend on it for a lot of things. It simply cannot be that broken!
I think it's because in its integration with the GUI of macOS, it works really well as an un
Re: (Score:2)
First, I defer to your knowledge of systemd. You say it is better; ok.
Note: I'm not a "fan" of systemd. I do like its basic init shit. Unit files really aren't bad, and once you get a grapple of units and targets, you can make the thing work for you in really good ways. The way systemd is being integrated into modern distros is a fucking joke, though. Distributions are replacing better software, with better maintainers, with systemd just for ease of package maintenance, and that sucks.
But how in the hell can launchd be as bad as you describe? Apple's OSes depend on it for a lot of things. It simply cannot be that broken!
I think it's because in its integration with the GUI of macOS, it works really well as an unseen component that makes their GUI perform like they want.
I.e., as terrible as it is to interface with launchd- as shipped, it does what Apple wants it to do perfectly.
So, launchd may not be wonderful; but it really isn't "broken", per se; just poorly documented. And while it isn't perfect, neither is systemd. Is that about right? ;-)
As for launchd being a pain to script, does a GUI launchd scripting tool like Lingon, albeit non-free, ease the pain for those who have better things to do than spend a week getting launchd to do their bidding?
https://www.peterborgapps.com/... [peterborgapps.com]
Re: (Score:2)
So, launchd may not be wonderful; but it really isn't "broken", per se; just poorly documented. And while it isn't perfect, neither is systemd. Is that about right? ;-)
launchd isn't broken- I said it's full of broken interfaces.
When one owns a Mac, they quickly realize that CLI tools to interface with Darwin aren't made for you- they're made for Apple.
This means Apple breaks interfaces (I don't mean remove- I mean breaks) without a care, because the interface they're currently using is maintained consistently throughout the tolls you're "supposed to" use in order to accomplish that goal.
As for launchd being a pain to script, does a GUI launchd scripting tool like Lingon, albeit non-free, ease the pain for those who have better things to do than spend a week getting launchd to do their bidding?
Not just to script- but to use at all.
And yes- tools where authors are maintaining
Re: (Score:2)
So, launchd may not be wonderful; but it really isn't "broken", per se; just poorly documented. And while it isn't perfect, neither is systemd. Is that about right? ;-)
launchd isn't broken- I said it's full of broken interfaces.
When one owns a Mac, they quickly realize that CLI tools to interface with Darwin aren't made for you- they're made for Apple.
This means Apple breaks interfaces (I don't mean remove- I mean breaks) without a care, because the interface they're currently using is maintained consistently throughout the tolls you're "supposed to" use in order to accomplish that goal.
As for launchd being a pain to script, does a GUI launchd scripting tool like Lingon, albeit non-free, ease the pain for those who have better things to do than spend a week getting launchd to do their bidding?
Not just to script- but to use at all.
And yes- tools where authors are maintaining the list the "current way that works" and turning it into a consistent interface work fine.
For my purposes, homebrew more or less manages this for me.
I guess you can just punt and use the old-skool stuff, like cron, right?
Re: (Score:2)
macOS is a pretty great desktop experience. But the underlying OS- Darwin- is a dumpster fire. The situation with launchd exists in just about every subsystem. It's an unholy mixture of undocumented interactions between competing systems that do the same thing.
It's entirely open source, and has a 0% server market
Re: (Score:2)
You can. There is no crond (it's handled by launchd), and as long as you don't ever rely on the config files (format and location changes often) and just use the crontab command, you're alright.
macOS is a pretty great desktop experience. But the underlying OS- Darwin- is a dumpster fire. The situation with launchd exists in just about every subsystem. It's an unholy mixture of undocumented interactions between competing systems that do the same thing.
It's entirely open source, and has a 0% server market share. There's a reason for that. Apple made it for Apple, not for Apple's customers. The GUI is for the customers. The OS is the foundation that Apple uses to give its customers that GUI.
People should be very careful looking at how macOS does things under the hood and thinking it's a good idea. As an underlying OS, linux is vastly easier to administrate and use just in the general sense.
Anyone who thinks linux upgrade breakage is hell has never used macOS. With linux it can be a coin toss whether or not things will break. With macOS, I set aside an entire evening to try to make my development stack work again.
Mac's magic is just the polish on the DE (and now their phenomenal processors)
I don't know that Apple ever pushed Darwin as a top to bottom OS. The fact that they didn't Open Source several critical SDKs was a clear indication of that. So it should be no surprise that Apple treats it like their own toy is not surprising. Besides, didn't others fork Darwin long ago? What's their excuse?
Re:yet another reason to dislike systmed (Score:5, Informative)
OK, there are two things here: systemd the service manager itself, and all the other things the systemd project has decided it needs to reimplement.
The systemd service manager itself is a poor implementation of some good ideas. Being able to define a service quickly in terms of the process lifecycle, action to take on failure, and so on makes it far easier to set up and manage services. The trouble is, the implementation is problematic in many ways, and the developers can't take any criticism.
The rest of the things the systemd project has decided to reimplment seem to be a total mess, where the out-of-the-box configuration is brain-dead, many important use cases have been forgotten, and lessons learned over the years have all been forgotten. The project seems to have a severe case of NIH syndrome, where they feel they need to replace all the utility services on Linux.
Re: (Score:2)
Re: (Score:2)
We all joke about "the year of the Linux desktop", but the reality is, it could never happen without SystemD--or something that looks like it.
SystemD gets a lot of hate, but SystemD is really only a small part of the overall "modern" Linux system that deviates significantly from old-school Unix.
D-Bus is really at the root of the changes to modern Linux. D-Bus allows you to programmatically manage other subsystems, such as SystemD (services and devices), NetworkManager (network), udisks (disk management), e
Re: (Score:2)
> D-Bus allows you to programmatically manage other subsystems, such as SystemD [...]
In Soviet Russia, SystemD manages you!
Re: (Score:3)
Seriously, can someone please explain to me why going to systemd benefits the distro?
As soon as you explain what you think this bug in a completely optional plugin has to do with systemd.
Re: (Score:2)
The plugin is definitely at fault; code - especially privileged code - should never use unvalidated external input to determine paths. A proportion of blame however has to lie with the systemd-networkd interface: the vulnerability derives from accepting string-valued updates off of D-Bus representing a set of enumerated values, but where the values and their string representation are completely undocumented.
The only way to validate these values is to copy/paste table data found in the bowels of the systemd
Re: (Score:3)
systemd rightly comes in for a lot of flack. It's been "taking over the world" a bit too much, and so even though this problem isn't actually in systemd, it's caused by it because some distros added this tool to help out with some problems caused by systemd.
FWIW, systemd Service Units (the config file that is used to start services) are really great. Sure, the syntax is crappy and was incrementally designed (badly), but you can get them to do what you need - and it's easy (much easier than writing bash scri
Re:yet another reason to dislike systmed (Score:5, Insightful)
That's easy. Here is the list:
Re: (Score:2)
The main benefit of systemd is that it replaces a messy collection of bash scripts that were inconsistent across distros, who's start up order was based on the filename, and had to be run to completion before starting the next one.
With systemd the distros get: 1) Consistency across distros. 2) Declarative instructions on how to start, stop, restart, what user to run as, dependencies, environment, and security settings. 3) A system of dependencies so you can ensure that services are started in the proper or
Networkd? (Score:2)
Good thing I disable that piece of shit first thing on any new install.
It causes a lot of headaches if you have a system with multiple interfaces, and I really can't be bothered with fighting the horrible config to get them all recognized and assigned to their proper networks.
The default config works fine if you have 1 network connection. Any more, or any weird combination, and you're going to spend hours just trying to get it to behave. So.. Disabled it is.
Re: (Score:2, Flamebait)
Yeah, typical Windows developer mindset: Any config the developer did not expect works badly or not at all. Pathetic not only on a *nix platform.
Re: (Score:1)
No network problems here, I did struggle with the wifi setup but that wasn't because of systemd.
Thanks for reminding me why I still use slackware (Score:4, Insightful)
Found? (Score:1)
Which version of Linux the patch is in? Seriously? (Score:2)
Debian doesn't offer any file named "networkd-dispatcher", not even in its contrib and non-free repositories. The closest match is "systemd-networkd", guess in what package it resides.
Re: (Score:2)
Unfortunately, there is a "networkd-dispatcher" package. My fault. I'm sorry.
correction (Score:2)
Microsoft finds flaw in a systemd component, fails to blame Lennart for the fiasco as they should have
M$ doing a study on a security flaw in Linux? (Score:1)
Surely there is no hidden agenda there!
Typical (Score:1)
Micro$oft can't fix their own security problems but "oooo! oooo! Look! Over there! THEY have a security bug!" Yawn....
Also note the Slashot Spin (Score:1)
BSD unaffected (Score:1)