Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Bug Debian Operating Systems Security Twitter Ubuntu Linux

Multiple Linux Distributions Affected By Crippling Bug In Systemd (agwa.name) 508

An anonymous reader writes: System administrator Andrew Ayer has discovered a potentially critical bug in systemd which can bring a vulnerable Linux server to its knees with one command. "After running this command, PID 1 is hung in the pause system call. You can no longer start and stop daemons. inetd-style services no longer accept connections. You cannot cleanly reboot the system." According to the bug report, Debian, Ubuntu, and CentOS are among the distros susceptible to various levels of resource exhaustion. The bug, which has existed for more than two years, does not require root access to exploit.
This discussion has been archived. No new comments can be posted.

Multiple Linux Distributions Affected By Crippling Bug In Systemd

Comments Filter:
  • by haruchai ( 17472 ) on Saturday October 01, 2016 @06:36PM (#52995981)

    and been around for 2 years and doesn't require root access??
    If this happened on Windows, I & many others would be scornful of it.

    • Re: (Score:2, Insightful)

      by bcarson ( 3960625 )
      There are plenty of people who don't need anymore reasons to hate on systemd. This won't get a pass just because it's Linux.
    • by Lumpy ( 12016 )

      Most of us ARE scornful of it and migrated away from distros that use it for our critical systems.

      • At least with Debian, can't you choose your init system at install time? Or is that no longer an option?

        I choose the distribution to meet my needs. I wouldn't allow the init system to dictate which distro I use.

        • by myowntrueself ( 607117 ) on Saturday October 01, 2016 @09:17PM (#52996541)

          At least with Debian, can't you choose your init system at install time? Or is that no longer an option?

          I choose the distribution to meet my needs. I wouldn't allow the init system to dictate which distro I use.

          Its moderately hard to choose the init at install time and requires some changes to the installers boot command.

          Its easy enough to strip out systemd after an install and trivially easy to upgrade from Wheezy to Jessie without systemd.

        • Running debian myself, there is/was a package to enable switching between init systems.

          Problem is, the distro has moved ahead full steam with systemd, whereby running an alternative init is unsupported by way of extensive testing.

          I used an alt-init for a while but for any moderately complex DE that requires the systemd-shim for session management (whatever that is!), weird stuff started to happen with dialog boxes telling me my permission levels were wrong or flakey stuff happening regarding acpi suspend/sh

    • by Daemonik ( 171801 ) on Saturday October 01, 2016 @08:22PM (#52996345) Homepage
      Please. If nobody reviewed the code then it's going to linger around until someone exploits it. Just like very friggen other piece of software ever written.
    • and been around for 2 years and doesn't require root access??
      If this happened on Windows, I & many others would be scornful of it.

      Apparently you haven't noticed all the posts here that have been hating on systemd since it was first introduced.

    • I wasn't able to reproduce on any of my systems. So, it is not as simple as stated in the summary. Maybe true on 2 years old systemd installations which haven't been upgraded since then. Hence the inflammatory statement about the bug being there for 2 years. Misleading summary AND blog article.
  • First of many (Score:5, Insightful)

    by somenickname ( 1270442 ) on Saturday October 01, 2016 @06:39PM (#52995989)

    Putting this level of complexity at such a low level of the system is going to cause show stopping bugs. And, with every new release, more complexity is added.

  • WONTFIX (Score:4, Funny)

    by Anonymous Coward on Saturday October 01, 2016 @06:41PM (#52995999)

    This is not a bug, it's a feature. This is the systemd way and you've all being doing it wrong!

    Regards,

    The Systemd Developers

  • Diversity (Score:5, Interesting)

    by K. S. Kyosuke ( 729550 ) on Saturday October 01, 2016 @06:48PM (#52996025)
    Fortunately, we have so many different Linux distributions that this is not a problem! (...right?)
  • Hot-buttered Karma; so delicious.
  • by Gravis Zero ( 934156 ) on Saturday October 01, 2016 @07:04PM (#52996087)

    All the people that were telling you that this init system called Systemd was overly complex, unaudited and insecure had warned you that this was coming. All the "Troll -1" modding on people that posted such warning here did not prevent the inevitable.

    Not convinced? Here's a graph of the number of issues opened/closed since systemd moved to github last year. [in.waw.pl]

    • by nnull ( 1148259 )
      I don't even need to worry about this bug, systemd already hangs my system when rebooting because it can't properly unmount or mount my network drives.
    • Sometimes (Score:3, Insightful)

      by Anonymous Coward

      when grey-haired conservative fuddy duddies warn of something, you should PAY ATTENTION even if you disagree.

      In this case, the "conservative" is certainly not in the political sense, it's in the technical sense. The core philosophy of UNIX was: small dedicated programs doing discrete things (which can be easily developerd, debugged, tested, and yes... replaced/substituted. Many warned that systemd was the polar opposite and would inevitably invite this very sort of issue. The warnings were ignored because t

  • Nope. Never bothered with systemd. Can't really claim foresight, just never felt like rebuilding all that plumbing.
  • Not sure if it's directly related to this, but since my desktop OS (openSUSE) has adopted systemd I've had a number of amusing incidents like this:

    Failed to start reboot.target: Activation of org.freedesktop.systemd1 timed out
    Failed to open /dev/initctl: No such device or address
    Failed to talk to init daemon.

    requiring a powercycle. Doesn't endear systemd to me in the least.

  • by Anonymous Coward

    Everyone who mocks these distributions for not toeing the Debhat line can all enjoy my "told you so".

    • by jmccue ( 834797 )

      Well, as a Slackware user I say "I informed you thusly".

      All joking aside, bugs happen, it was fixed quickly and I assume patches went out. All it seemed to do was crash a system, as bugs go I can think of worse (shellshock).

  • by Anonymous Coward

    I strongly urge people to RTFA for a detailed description of some of the technical problems with systemd.

    It feels surreal that the most senior people in the Linux community, after decades of attempting to put out a credibly secure client and server platform, suddenly almost all decided to switch to this product.

    • Re: (Score:3, Informative)

      by F.Ultra ( 1673484 )

      That is far from a detailed description and more of a list of uninformed rants. Much better to read the informed reply to TFA here: https://medium.com/@davidtstra... [medium.com]

      What does feel surreal is that people now all of a sudden pretend that SysV init where without exploits while going completely berserk when systemd have a non remote exploitable denial of service bug that cannot be used to take over the machine that also where patched three days ago...

      • Re:RTFA, please. (Score:5, Interesting)

        by grcumb ( 781340 ) on Saturday October 01, 2016 @08:39PM (#52996415) Homepage Journal

        That is far from a detailed description and more of a list of uninformed rants. Much better to read the informed reply to TFA here: https://medium.com/@davidtstra... [medium.com]

        More clueless autonomic defensiveness without any reflection on what the impact of the bug actually is. I especially enjoyed this old chestnut as the author attempts to fisk the original bug report:

        These accusations are true for every major production kernel (Windows, Linux, and BSD) and every alternative to systemd (in the sense that they’re almost all written in C and run many of their operations as root).

        "SystemD, let me just stop you there. I know the Linux kernel. I've worked with the Linux kernel. You're no Linux kernel."

        The incredible hubris of asserting parity with the core of the entire OS, the ignorance that underlies the statement that init was written in C and runs as root, so it's every bit as vulnerable... How the fuck do you even make code run? Do you even teh logic?

        The SystemD team is the Microsoft of a new generation. Doubling down on their mistakes; shouting louder when they don't get their way; using every available ratiocination and intellectual contortion to excuse themselves; resorting to any means to make their strategy win, instead of stopping to ask themselves for once, 'Are we following a winning strategy here?'

        Thank g*d I quit writing software last year. Dealing with Microsoft's mind-crushing blindness was enough for one lifetime. Now I can just grump about it and walk away.

  • by Anonymous Coward on Saturday October 01, 2016 @07:43PM (#52996203)
    https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post-c2ccaa58661d
    Can't have anyone criticizing any aspect of the holy systemd.
    Whole thing boils down to:
    "Following security practices in an init system is hard, and you've never done it so leave us alone."
    Completely ignoring the fact that the only reason they patched this thing is because he made a big deal out of it.
    And on what planet is testing for corner cases like empty strings the domain of fuzz tools?
    That seems like a pretty standard test case to me.
    I can understand if you don't test for a 1MB string, but empty seems like a no brainer.
    • Re: (Score:3, Insightful)

      by Anonymous Coward

      https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post-c2ccaa58661d
      Can't have anyone criticizing any aspect of the holy systemd.
      Whole thing boils down to:
      "Following security practices in an init system is hard, and you've never done it so leave us alone."
      Completely ignoring the fact that the only reason they patched this thing is because he made a big deal out of it.
      And on what planet is testing for corner cases like empty strings the domain of fuzz tools?
      That seems like a pretty standard test case to me.
      I can understand if you don't test for a 1MB string, but empty seems like a no brainer.

      For those who don't want to follow OP's link [medium.com]:

      The systemd project applies both unit testing and static/dynamic analysis to systemd. We’ve done this for years; I ran the first Coverity scans myself. Testing inputs of empty strings, excessively large data structures, and other invalid permutations is the realm of fuzz testing, which is a recent project even for the Linux kernel. Despite Linux being used for critical systems for decades, fuzz testing only began as side-projects “in beta” in 2007 and more earnestly in 2013. It’s clearly a valuable technique, but implying that comprehensive testing of invalid inputs is “obvious” is misleading about the state of major projects.

      WHAT

      THE

      FUCK?!?!

      It's too much to expect systemd to test for invalid inputs from non-privileged user-space?

      Are you fucking kidding me?!?!?

      Who the fuck is David Strauss? And when is he scheduled to matriculate from kindergarten?

      Too much to expect him to test?!?!!?!

      Pathetic. Thalidomide-brain pathetic.

      • Well, at the very least, be glad that these guys are just writing your init system and not your website.

        -- Little Bobby Tables

      • Maybe linux hackers are a bit slow on the uptake but automated builds and coverage of unit testing has been standard practice in 'Agile' circles for over a decade.

        'fuzzing', according to wikipedia, was pioneered in 1988.

    • by Anonymous Coward

      Oh geez. He spends his entire diatribe picking apart each one of Ayers's points and saying each one thing alone isn't reason enough not to use systemd. No, maybe not. But all of those things PUT TOGETHER add up to plenty of reason not to use systemd.

      I like the contradiction here as well:

      "implying that comprehensive testing of invalid inputs is 'obvious' is misleading about the state of major projects"

      then later,

      "It's a stretch to use the label 'parsing' for what is mostly a string comparison against a fixed

  • OpenRC (Score:5, Insightful)

    by Shane_Optima ( 4414539 ) on Saturday October 01, 2016 @07:47PM (#52996211) Journal
    If you're dissatisfied with systemd and you don't need any of its fancier capabilities (which as an end user I'm assuming would be Docker stuff), please consider switching to a non-systemd distro as soon as possible and (if you can afford the time or money) contributing to their development. The more support systemd alternatives can garner, the more likely it is that projects to will resist unnecessary systemd dependencies and it might even be that systemd itself will eventually become more modular and moddable.

    I'm not a hater. I cringe every time I see +5 comments claiming that systemd didn't fix anything. Declarative syntax is (at least in principle) a massive win, especially for distro builders. And LXC is amazing stuff, and I certainly cannot fault Red Hat for wanting containers to behave perfectly. Unless something like Genode scores a major coup, containers are definitely the future of secure and robust computing.

    But the actual details of systemd's course have been hair-raising. It needs to be more UNIX-like and less draconian in its requirements and less toxic in its effects on the FOSS ecosystem and unfortunately (given Red Hat's behavior over the past decade) it appears that pushing alternatives hard is the only way they can conceivably be convinced to change their ways or reform anything moving forward.

    I encourage all of the haters here to try and put your money where your mouth is. Install, use, support and help promote a distro like Devuan or even better: go and find one of the multiple OpenRC distros available. OpenRC can't be the all-in-one automagic solution systemd endeavors to be, but it doesn't hide tons of stuff in huge C binaries and it's addressed most of the common frustrations people have with SysV. Arch Linux has an OpenRC variant (the standard install uses systemd), Gentoo was the distro that started OpenRC years ago, and Alpine linux uses it (which isn't an ideal easy desktop distro, but it's amazing for those wanting a secure minimal distro to build on and last time I checked it does run XFCE and Firefox.) There are probably others.
    • by Artemis3 ( 85734 ) on Saturday October 01, 2016 @08:47PM (#52996443)

      In the meantime you may avoid using systemd as init in Debian by installing sysvinit-core [debian.org] or in Ubuntu by installing upstart-sysv [ubuntu.com] in your transition to a systemd-less distro such as Devuan [devuan.org].

      If you are using Debian Jessie, you can switch to Devuan by simply changing repositories. Its still in beta so don't do it on production servers yet. But do plan your migration, before this gets out of hand.

    • by dbIII ( 701233 )

      containers are definitely the future

      Only if the future is 2004!
      It was done before Lennart heard of anything other than MS Windows.

  • by 93 Escort Wagon ( 326346 ) on Saturday October 01, 2016 @08:03PM (#52996275)

    "Debian, Ubuntu, and CentOS are among the distros susceptible to various levels of resource exhaustion."

    Whew! Thank goodness I run Red Hat!

  • It's the only way to be sure.

  • by fahrbot-bot ( 874524 ) on Saturday October 01, 2016 @09:40PM (#52996615)

    The developers haven't stopped at what systemd needs to do and have gone on to what they want it to do, favoring the latter over the former.

  • This is why the mass standardization of Linux is a bad thing
  • Not surprising (Score:5, Interesting)

    by MrKaos ( 858439 ) on Sunday October 02, 2016 @01:07AM (#52997443) Journal

    I've made several requests for systemd proponents to supply a use case that SysV initd could not support and haven't received a satisfactory reply to this purely technical question. I was interested in what systemd could offer over initd. I find systemd proponents are overly veherment in their criticisms of initd proponents.

    I sense this comes from an inability to address the issues raised and, perhaps a mindset that anyone who has an appreciation for initd's elegant power will simply be bulldozed into irrelevance. I think systemd's criticism of the rc scripts that starts a linux based system is valid criticism however we have to keep in mind that they were devised by Red Hat. It is dealing with rc shell scripts that are the brunt of the justification for systemd.

    In that sense the unitd solution is tidy but also reveals the justification to replace initd is not based on a full understanding of its capabilities, or even an understanding of was it is, a process manager. rc scripts are only meant to prepare the system for entries in /etc/inittab, yet everyone tries to get everything done in rc, which serializes the Linux boot process. A parallell boot is completely achievable by using initd properly. I know there is more to it, like events and messaging, I'm just citing one example.

    Yet I've never seen a Linux distro that's utilized initd's /etc/inittab file properly. Especially a Red Hat system. They don't use initd properly, the rc scripts are bloated with rewrites of what initd already does, and now we're replacing initd, keh? initd has yet to be utilized fully on modern linux systems.

    Criticisms of sco the company aside: sco *as a distribution of unix* had an interesting adjunct feature to initd, the 'enable' and 'disable' command that managed entries in /etc/inittab, where you would configure the characteristics of the system you were running. Franky I think this is functionality is essentially

    sed -i -e '/someProcess/ s/:on:/:off:/' /etc.inittab ; kill -1 1

    I think initd would make a lot more sense to more people if this functionality had been available in Linux from the beginning. It is true that initd is beguiling in terms of it's simplicity wrt its power, but it is also very worthwhile. It is supposed to be small as that is where the skill is expressed.

    initd is where you design the characteristics of the system, it is not an event manager and all the other things systemd is supposed to be. Something that does all the functionality systemd has, belongs as an inittab enty, not as the first process the kernel runs.

    The point of a bug like this is not that it is a big deal itself, the big deal is the failure mode systemd has been revealed to have due to its complexity. This the type of concern I have about systemd, what else can trigger such a failure mode. I have seen initd in a variety of failure modes and not once has it ever consumed all system resources and disconnected running processes.

    Now we've seen systemd do something that initd can't.

Fundamentally, there may be no basis for anything.

Working...