Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Bug Security Linux

Nasty Linux Systemd Security Bug Revealed (zdnet.com) 203

Qualys has discovered a new systemd security bug that enables any unprivileged user to cause a denial of service via a kernel panic. Slashdot reader inode_buddha shares the news via ZDNet's Steven J. Vaughan-Nichols: As Bharat Jogi, Qualys's senior manager of Vulnerabilities and Signatures, wrote, "Given the breadth of the attack surface for this vulnerability, Qualys recommends users apply patches for this vulnerability immediately." You can say that again. Systemd is used in almost all modern Linux distributions. This particular security hole arrived in the systemd code in April 2015.

It works by enabling attackers to misuse the alloca() function in a way that would result in memory corruption. This, in turn, allows a hacker to crash systemd and hence the entire operating system. Practically speaking, this can be done by a local attacker mounting a filesystem on a very long path. This causes too much memory space to be used in the systemd stack, which results in a system crash. That's the bad news. The good news is that Red Hat Product Security and systemd's developers have immediately patched the hole.

This discussion has been archived. No new comments can be posted.

Nasty Linux Systemd Security Bug Revealed

Comments Filter:
  • by Gavino ( 560149 ) on Tuesday July 20, 2021 @08:29PM (#61602931)
    Systemd HATE!!
    • by RightwingNutjob ( 1302813 ) on Tuesday July 20, 2021 @08:37PM (#61602945)

      All totally unjustified. The science is settled.

      I mean...it's not like this is exactly the class of problems made possible by a piece of software that tries to do everything at once as opposed to multiple pieces of software siloed off from eachother in different address spaces.

      Pish posh.

      • Yes. Complete agreement.
      • by enigma32 ( 128601 ) on Tuesday July 20, 2021 @09:21PM (#61603025)

        What "science is settled"?

        While I agree this particular issue is no reason to hate on systemd in particular, there are many legitimate reasons to prefer other approaches over the systemd mess.

      • Re: (Score:3, Insightful)

        by iggymanz ( 596061 )

        of course my init system should be the login manager and sync the time in an inferior manner to ntpd while losing logs and seizing up the system when boot trouble arises!

        harumph! harumph!

        • by Antique Geekmeister ( 740220 ) on Tuesday July 20, 2021 @10:09PM (#61603159)

          And terminate background processes when you log out, with no record of having done so. That one was a surprise for sys-admins who used "nohup" to start background jobs and might lose their shell connection to a distant host.

          https://linux.slashdot.org/sto... [slashdot.org]

          • by jabuzz ( 182671 )

            More screen or tmux, than nohup, and it didn't actually go very far.

            However it is highly instrumental in showing that Pottering has zero experience as an actual sysadmin.

        • by arglebargle_xiv ( 2212710 ) on Wednesday July 21, 2021 @12:25AM (#61603317)
          And don't forget the totally broken sort-of-resolver systemd-resolved.service that it bulldozes in to replace your existing one. You know, the one that sort of works some of the time, so you need to:

          sudo systemctl disable systemd-resolved
          sudo systemctl stop systemd-resolved
          sudo systemctl mask systemd-resolved

          on every system you have. And then systemd complains endlessly that you're running a resolver that works, and it wants its broken one back or else!

          • by Junta ( 36770 )

            To be fair, the standard nss resolver is pretty limited.

            You can have some search paths and then a list of dns servers expected to resolve everything identically.

            If you want to use a different DNS for 'myhouse.net' versus internet lookup versus 'workvpn.com' versus 'clientvpn.com', you have to set up your own dns server. Having that baked into a system resolver is nice. Though it is weird that you go through the nss code to query local dns meaning some work is needless/duplicated, but it's a more trivial pro

            • Ya. That's the shitty choice we're left to make.
              NSS implementation is generally lacking in feature set (though it could be extended- that's the damn point of NSS- someone just needs to write the damn code)
              And so if you want some nice features of a modern resolver that you'd find in... well, any other operating system, you're left with resolved's attitude toward compatibility, where the maintainer's opinion of the RFCs for DNS are draconian and wrong-headed.
              He seems to be able to read the rules on what is
      • by phantomfive ( 622387 ) on Tuesday July 20, 2021 @10:42PM (#61603191) Journal

        I have never written a shell script that had a problem with alloca(). I'm glad systemd went backwards to make that possible.

        • by AmiMoJo ( 196126 ) on Wednesday July 21, 2021 @04:56AM (#61603759) Homepage Journal

          GNU Bash has a long list of critical (many rated 10/10) vulnerabilities: https://www.cvedetails.com/vul... [cvedetails.com]

          I'm sure other shells do too.

          As for init systems there was some security through obscurity since people often had their own custom ones, but many also relied on the default scripts shipped by distros that sometimes had security flaws in them.

          • GNU Bash has a long list of critical (many rated 10/10) vulnerabilities

            Yeah, and systemd left all those in, while adding a bunch of its own.

        • You sir, didn't try hard enough.

          This "mistake" is only triggered intentionally. It's not something you will accidentally do.
          This makes it akin to any of the multitudes of shell bugs that have turned into exploits.
      • by slack_justyb ( 862874 ) on Tuesday July 20, 2021 @10:49PM (#61603197)

        I mean...it's not like this is exactly the class of problems made possible by a piece of software that tries to do everything at once as opposed to multiple pieces of software siloed off from eachother in different address spaces

        Well it would happen with anything PID 1, that's making the kind of call this program makes. The issue is unchecked alloca.

        Like quick aside here, there's a roaming group of folk on Slashdot that are always like, "we don't need new programming tools, we just need better programmers". So this is one of those times those people need to chime in, because this same thing would happen if BSD mount was using unchecked alloca.

        That said, the core issue is that PID 1 relies on alloca but doesn't check the input size. systemd-mount, which is what is calling for the mounting, reports the name back to PID 1 to "register" the mounted volume. The program systemd-mount and systemd itself are indeed different address spaces. unit_name_path_escape is calling strdupa (string dup with alloca) which alloca allocates bytes of memory up to ulimit -s size, because it pins the memory to the current stack frame. Now I'm sure one of our C brethren that are floating out there would yell, "Either use strndup or check the size of the char* before you send to alloca!!" And they would be correct...

        Okay anyway, at the risk of making this a super sized comment. The point being, bad C code, not checking inputs, and code review failing at catching any of this. That happens with any piece of software. It isn't something unique to systemd. And systemd's style of handling things doesn't make it more prone to other processes sending BS to it to crash. Also, to trigger this, you need to mount something with 8MBs in the path name. That's a "mount -t ext /var/8mbofgrabage /blahblahblah" and that's not coming from the user, nor is that coming form udev. So why is someone allowing people from outside to mount on a box? But whatever, again, that's beside the point.

        Now if someone wants to use this as evidence that the systemd team have no idea what they're doing or their code review is bunk. That's outside of the conversation I want to have since I have to have those kinds of talks with people at work. But point being is that if BSD mount had no check on a call to alloca, init scripts would fail if someone got an 8MB entry into your fstab, on reboot. And it wouldn't have to be mount, if there was an issue in BSD init that handled SIGHUP, and you SIGHUP a proc that's execution path was over the limit and for some dumb reason BSD was using strdupa in this call without first doing a check on the size, then you could trigger it on a kill -1. Now of course, BSD devs would have caught someone doing something as dumb as this and had them up on a pike, but the point being this is bad programmer and less bad design. Which don't get me wrong, I'm no fan of systemd design either, but let's put things into the correct boxes here.

        • So the init script managing mount/automount crashes. / is still mounted so the system is probably still functional-ish. init doesn't crash. Getty/login/sh shouldn't crash unless somehow they ended up in that directory. Updating boot0 might lose its shit. sysvinit, busybox init, and so forth... none of them *care* about mounts; they are a *user* problem. They don't track them, nor try to monitor which process is in which namespace: they give zero craps about anything except if there is a child process it nee

        • by Tom ( 822 ) on Wednesday July 21, 2021 @03:18AM (#61603571) Homepage Journal

          The point being, bad C code, not checking inputs, and code review failing at catching any of this. That happens with any piece of software.

          No, it doesn't.

          This is the case where the "bad programmers" argument is actually RIGHT. I know my students hated me during the C programming excercises, but they sure as hell learnt input validation. It took some of them 3 or 4 times being sent back with a segfaulted program to understand that it's not enough to check for whatever I put in the last time to make it crash, because I'll do something different the next time, and that they should ensure the input is what they expect.

          Not validating your input does NOT happen to any piece of software. It's exactly what happens when you let bad programmers write kernel code, where no framework catches their mistakes.

        • No it wouldn't. Init is small, simple and does 1 task with a far smaller code attack vector and what code there is has been debugged for literally decades. If one of its child processes crashed the chances are the system would carry on albeit with some functionality missing that could be addressed by a sysadmin.

        • by AmiMoJo ( 196126 )

          This is the kind of flaw that should be caught by static analysis.

          For once Microsoft was on the right track here with deprecating functions that don't set size limits. The developer can still set the limit to some ridiculous value but at least it forces them to think about what the limit should be.

          In fact for functions like alloca should really be deprecated for many reasons. Stack overflow is undefined behaviour, for example.

        • by Megane ( 129182 )

          The point being, bad C code, not checking inputs, and code review failing at catching any of this.

          Code review? In my Poettering-ware?

        • Well it would happen with anything PID 1

          You clearly do not understand the issue here. Yes, of course it could happen withing anything PID 1. That is why whatever PID 1 is doing should be VERY LIMITED IN SCOPE.

          This is exactly what all of the yelling and screaming was about and you dismiss it as: Of course it could happen with anything PID 1. Deaf and dumb.

          • That is why whatever PID 1 is doing should be VERY LIMITED IN SCOPE.

            See people wonder why people are bad at C and this is why. So how fucking limited in scope should init be? Should it be so limited that you cannot pin allocation on top the stack frame? Hmm? Should there only be a subset of allocation methods acceptable to use in an init? Because any use of alloca() including strcmpa() would trigger this. In fact several of the GNU GCC specific allocation methods suffer from ease of corruption because it requires validating input.

            you dismiss it as: Of course it could happen with anything PID 1

            And this is why C is a dead language,

            • by jeremyp ( 130771 )

              Maybe you should read the man page for alloca [man7.org].

          • by DarkOx ( 621550 )

            Actually if you read his entire comment he points out rather clearly that; an exploit like this in the conventional mount binary would be probably just as bad. It would result from the same kind of failure to check inputs/buffers, and it would still a privileged binary. RCE with root privs is what it is.

            You are also not wrong that systemd being what is does offer a lot of extra footpint, and for issues like DOS it might take the blast radius from something very small to system wide. I am firmly in the syste

            • Actually if you read his entire comment he points out rather clearly that; an exploit like this in the conventional mount binary would be probably just as bad. It would result from the same kind of failure to check inputs/buffers, and it would still a privileged binary. RCE with root privs is what it is.

              However, it's not, because mount is suid root.

              It'd be more like if mount, instead of directly calling mount() by the kernel (which handled permissions for you) were actually handled by some kind of mountd process running as root, and then had its privileges and inputs validated by... significantly less competent individuals, who may even believe that certain mistakes are actually the right way to do something, and you just shouldn't send his daemon garbage.

        • The fact that they're separate processes isn't relevant, since PID1 is what does the actual mounting, but by request of systemd-mount.
          There's a valid argument that the only reason our stupifying unvalidated alloca() exists within PID1 (in such a way that accepts arbitrary fucking input from anyone on the system) is due to poor design of an init system, where PID1 really needs to avoid doing... well, anything that can cause it to crash, as in terms of system stability, a failure of PID1 is as grave as a fai
    • by Anonymous Coward on Tuesday July 20, 2021 @09:40PM (#61603079)

      initctl start hate target=systemd

    • I think you mean cue, but the use of queue is amusing in some ways in this context.
    • systemd *is* a bug.
    • It should bring out the whiners and fossils alike
  • by sk999 ( 846068 ) on Tuesday July 20, 2021 @09:26PM (#61603035)

    The one bit of systemd code that I inspected replaced a bash script in the old init system with vanilla C code that only did string manipulation - nothing binary. Why? Those string functions have more holes than a slice of Swiss cheese. What caused the current nasty security nightmare? A string function.

    • by Cyberax ( 705495 )

      What caused the current nasty security nightmare? A string function.

      Nope. It was alloca() returning error if given a 1Gb path (one GIGABYTE long path). The kernel also can't handle this well and panics anyway.

      • by bill_mcgonigle ( 4333 ) * on Tuesday July 20, 2021 @10:06PM (#61603141) Homepage Journal

        > one GIGABYTE long path

        Hrm? The disclosure says 8MB:

        As a result, if the total path length of this mountpoint exceeds 8MB
        (the default RLIMIT_STACK), then systemd crashes with a segmentation
        fault that also crashes the entire operating system (a kernel panic,
        because systemd is the "global init", PID 1).

        Either way, Debian folks look here: https://security-tracker.debia... [debian.org]

      • by sk999 ( 846068 )

        >>Nope. It was alloca()

        The article that I read said that the bug was introduced by a programmer who:

        "... replaced a strdup() in the heap with a strdupa() on the stack."

        So the programmer was replacing a POSIX string function with well-defined behavior with a non-POSIX string function that called alloca, which lacks said well-defined behavior. So I guess we are both right. The real problem, though, is that it appear to be that there is no process control on the programmers of systemd - make use of wha

        • I saw that this morning when there were a lot of pending updates on my machine, and the changelog description for most of them said little more than "don't use strdupa()". I was thinking: WTF? I didn't even know there was a strdupa() function. Everyone knows that you shouldn't ever use alloca(). Does it call that in turn?

          I looked up its manpage, and the answer is yes, this nonstandard GNU-specific extension does call alloca().

          The fact that this high-profile mission critical project had such a blatant blunde

        • I hate panics. Ruins my system uptime bragging rights.

          Uptime bragging is still a thing?!

      • by sjames ( 1099 )

        No, the kernel does not panic over alloca. The kernel doesn't even get involved in alloca, it's purely an adjustment to the stack pointer in the process. If the program tries to alloca more space than the stack has, the next code that touches the stack will likely trigger SIGSEGV, killing the program. In this case, systemd.

        This absolutely points to a serious design flaw of systemd as well as a bug. The bug is using alloca having no idea if there is enough room on the stack for the request or not.

        The design

      • alloca() is not ANSI C. Just using malloc() should've prevented this [as memory comes from heap not stack]. That is code not just for say posix compliance; but when possible ANSI compliance.
      • You're kinda getting warm but you mangled the details anyway, so you're kinda an idiot.

    • A strdupa instead of a strndupa. String functions aren't the issue per se, unbounded string functions are. Just never do that.

  • Meh (Score:5, Interesting)

    by llamalad ( 12917 ) on Tuesday July 20, 2021 @10:34PM (#61603187)

    As a card-carrying cranky old recovering sysadmin I get as excited as anyone about the latest systemd faceplant. Because in my day we had sys v and bsd init and we liked it. We liked it just fine.

    But I digress. This isnâ(TM)t even that big a stumble. Itâ(TM)s a little egg on face at worst for the team, itâ(TM)s no big deal for shops who do security right (principle of least privilege and defense in depth notifications it at least twice over), and itâ(TM)s potentially a hassle for admins of multiuser systems with malicious or capricious users.

    Now, if it were remotely triggerable that⦠(is it? I only read the summary. Or, you know. Glanced at it). Iâ(TM)d have a good chuckle over that one. Because Devuan and the various BSDs all exist and are viable choices. Or unikernels, even.

    • by Tom ( 822 )

      As a card-carrying cranky old recovering sysadmin I get as excited as anyone about the latest systemd faceplant. Because in my day we had sys v and bsd init and we liked it. We liked it just fine.

      So with you on that.

      When I read about systemd my first thought was "isn't that the OPPOSITE of how a Unix system works? You know, make small pieces that do one job and do it well, then make them talk to each other?"

      But hey, like 5 years from now someone will come up with something novel like a domain concept or subsystem framework to split the monster into smaller parts, for stability and security reasons. Then they'll invent a new virtual filesystem to access those subsystems. Then they'll spend a decade o

      • When I read about systemd my first thought was "isn't that the OPPOSITE of how a Unix system works?

        Depends on how you think your UNIX system works. I assume you don't actually do anything with your system, i.e. run a GUI. God knows there's nothing Unix philosophy like about any of the current GUIs out there. Nor are many of the programs we use UNIX for.

        Do one thing and do it well is all good and fine if that one thing is actually useful. There's a reason every man and their dog attempted to replace sysv init, while it did its one thing well, blindly executing a program while throwing a PID state file int

        • by Tom ( 822 )

          I assume you don't actually do anything with your system, i.e. run a GUI.

          Two of my Unix systems run a GUI. My server, of course, doesn't.

          God knows there's nothing Unix philosophy like about any of the current GUIs out there.

          X was closer to the original philosophy, yes. But it's still less monolithic than Windows.

          Nor are many of the programs we use UNIX for.

          A lof ot the ones I use are. But yes, it depends on what you do with your system. And anyway we weren't talking applications, but system-level.

          There's a reason every man and their dog attempted to replace sysv init

          There's also a reason they all failed.

  • Almost, not mine...or so I thought. This makes me want to cry, being FORCED to use systemd (even a part of it) just to get standard software to work:

    https://alien.slackbook.org/bl... [slackbook.org]

    This will be Slackware-15 (-Current er currently). What to do?

    • What to do? Use a real operating system such as OpenBSD.
    • by xalqor ( 6762950 )
      I remember installing Slackware from floppy disks... Anyway check nosystemd.org [nosystemd.org] and wikipedia [wikipedia.org]
    • There are lots of systemd-free Linux distros. See wikipedia:
      https://en.wikipedia.org/wiki/... [wikipedia.org]

      • by storkus ( 179708 )

        There are lots of systemd-free Linux distros. See wikipedia:

        As with much of Wikipedia this seems a little out of date (at least only a little!).

        As AlienBob discussed in the blog, ELoginD is has to be integrated to get PAM & even parts of KDE to work, replacing ConsoleKit. Even though elogind is supposedly "cleaned and sanitized" and clean-forked from systemd-proper, its a little un-nerving.

        On "nosystemd.org" it also still shows Slackware, so I may be over reacting; I hope so. Interestingly, Parabola is shown as well.

        As for the suggestion of OpenBSD (or any BSD)

  • by stanbrown ( 724448 ) on Wednesday July 21, 2021 @03:19AM (#61603573) Homepage
    Once again, we suffer from the failure of the developers of this tool to understand the long established *NIX philosophy of doing one (small) thing, and doing that one thing well. The code for something as big and complex as systemd will always be a huge risk, and what value does this bring?
  • Fucking idiots. Never heard of strndup? (Or in this case, strndupa)

    Nobody should ever use strdup. Ever. Go sit in the corner now.

    • Don't the strn functions return pointers to undelimited strings? Quite awful. What do they do with UTF-8 strings? Can they return strings ending in half a UTF-8 character? Awful again.

      You have a situation here where crashing on bad input allows a DOS attack. So if you can't mount a filesystem with an 8MB path, and you can't respond by crashing, the best you can do is log an error and make sure that your code does effectively nothing on an attempt.
    • by Junta ( 36770 )

      strndupa could be similarly bad, as they probably weren't being mindful of this specific limit. The problem is stack corruption resulting from large alloca, whiich strndupa would happily do, given a large enough constraint. Or, alternatively, if the function might be inlined by compiler optimization and called many times in a 'calling' function, in which case even a small alloca could create issues. Here the string was properly allocated and properly terminated, it was just too big to be suitable for someth

  • by mugurel ( 1424497 ) on Wednesday July 21, 2021 @04:43AM (#61603733)
    alloca() allocating a la loca
    • by Megane ( 129182 )

      Should alloca() be Considered Harmful? I had vaguely heard of it before, but wasn't familiar with it because I don't use it. Now that I have read about it, it seems to be another argument in favor of C99, this time because of Variable Length Arrays. Too many people out there are still using "C89 with // comments", despite it being over 30 years old. (And yes, C99 is 20+ years old, but later enhancements are much less fundamental.)

      https://stackoverflow.com/questions/1018853/why-is-the-use-of-alloca-not-con [stackoverflow.com]

  • Thank goodness all the bugs are in systemd and no longer in any other part of Linux. Those systemd contributors must be so stupid.
  • So tell me again how Linux is secure and Windows is not?

    LOL... slashdoters have been huffing your own farts for so many years.

Were there fewer fools, knaves would starve. - Anonymous

Working...