Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security Linux

Microsoft Finds Linux Desktop Flaw That Gives Root To Untrusted Users (arstechnica.com) 75

Posted by BeauHD from the make-sure-you're-updated dept.
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.
This discussion has been archived. No new comments can be posted.

Microsoft Finds Linux Desktop Flaw That Gives Root To Untrusted Users More

Microsoft Finds Linux Desktop Flaw That Gives Root To Untrusted Users

Comments Filter:

  • 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: (Score:2, Interesting)

    by account_deleted ( 4530225 )
    Comment removed based on user account deletion
    • Microsoft seems pretty comfortable with the niches that Windows and Linux have settled into. Nobody forced WSL into Windows at gunpoint as far as I know, yet there it is, right out of the box.
      • Yeah, the thing they kept screaming about for 2 decades is now a feature in Windows. Even better it spawned the WSA /running Android apps Hopefully it's not the beginning of the end

    • (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.

  • The discussion at arsTechnica describe this as a problem for only Debian, Ubuntu and derivatives based on availability of the networkd-dispatcher package.

  • yet another reason to dislike systmed (Score:5, Interesting)

    by stanbrown ( 724448 ) on Wednesday April 27, 2022 @05:41PM (#62485342) Homepage
    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?

    • Re:yet another reason to dislike systmed (Score:5, Interesting)

      by StormReaver ( 59959 ) on Wednesday April 27, 2022 @06:08PM (#62485374)

      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)

        by Anonymous Coward

        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

        • because I'm a Gentoo user

          What is the share of Gentoo users between other linux users? (asking because I only know Gentoo users here on /. ...)

        • Re: (Score:2)

          by HiThere ( 15173 )

          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).

      • 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.

    • 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)

        by DamnOregonian ( 963763 ) on Wednesday April 27, 2022 @09:06PM (#62485746)
        Mac user, here. launchd is a pile of flaming excrement.
        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.

        • 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)

            by _merlin ( 160982 )

            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.

          • 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

            • 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]

              • 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

                • 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?

                  • 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

                    • 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)

      by _merlin ( 160982 ) on Wednesday April 27, 2022 @08:39PM (#62485696) Homepage Journal

      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)

      by decep ( 137319 )

      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

      • > D-Bus allows you to programmatically manage other subsystems, such as SystemD [...]

        In Soviet Russia, SystemD manages you!

    • 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.

      • 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

    • 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)

      by rastos1 ( 601318 ) on Thursday April 28, 2022 @07:21AM (#62486374)

      Seriously, can someone please explain to me why going to systemd benefits the distro?

      That's easy. Here is the list:

    • 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

  • 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)

      by gweihir ( 88907 )

      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)

      by Isaac-Lew ( 623 )
      3 interfaces (ethernet, wifi & vboxnet) along with loopback.

      No network problems here, I did struggle with the wifi setup but that wasn't because of systemd.

  • Or injected?

  • 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.

  • Microsoft finds flaw in a systemd component, fails to blame Lennart for the fiasco as they should have

  • Surely there is no hidden agenda there!

  • Micro$oft can't fix their own security problems but "oooo! oooo! Look! Over there! THEY have a security bug!" Yawn....

  • I submitted this story 2 days before it appeared on /. but they didn't like my framing of this being a SystemD / DBUS issue. Instead they choose this alternative language to obfuscate the true issue here: systemd has repeated proven to have shitty security and make things worse, not better. FACTS. They totally are trying to spin this and minimize the fault of systemd.
  • No systemd. Users allergic to DBUS and often disable it. Woot.

Slashdot Top Deals

"Conversion, fastidious Goddess, loves blood better than brick, and feasts most subtly on the human will." -- Virginia Woolf, "Mrs. Dalloway"

Close