Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Monday July 03 2017, @10:12PM   Printer-friendly
from the it's-a-feature dept.

Submitted via IRC for TheMightyBuzzard

A bug in Linux's systemd init system causes root permissions to be given to services associated with invalid usernames, and while this could pose a security risk, exploitation is not an easy task.

A developer who uses the online moniker "mapleray" last week discovered a problem related to systemd unit files, the configuration files used to describe resources and their behavior. Mapleray noticed that a systemd unit file containing an invalid username – one that starts with a digit (e.g. "0day") – will initiate the targeted process with root privileges instead of regular user privileges.

Systemd is designed not to allow usernames that start with a numeric character, but Red Hat, CentOS and other Linux distributions do allow such usernames.

"It's systemd's parsing of the User= parameter that determines the naming doesn't follow a set of conventions, and decides to fall back to its default value, root," explained developer Mattias Geniar.

While this sounds like it could be leveraged to obtain root privileges on any Linux installation using systemd, exploiting the bug in an attack is not an easy task. Geniar pointed out that the attacker needs root privileges in the first place to edit the systemd unit file and use it.

[...] Systemd developers have classified this issue as "not-a-bug" and they apparently don't plan on fixing it. Linux users are divided on the matter – some believe this is a vulnerability that could pose a serious security risk, while others agree that a fix is not necessary.

See, this is why we can't have nice init systems.

Source: http://www.securityweek.com/linux-systemd-gives-root-privileges-invalid-usernames


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by frojack on Tuesday July 04 2017, @01:25AM (6 children)

    by frojack (1554) Subscriber Badge on Tuesday July 04 2017, @01:25AM (#534630) Journal

    Okay why the FUCK would an undefined value like this ever, EVER default to root?!

    Lazy developers of systemd is my guess. They didn't want to have to have a user = clause in every friggin unit.

    They started developing things for an init that runs system things, and only later added the ability to start tasks for user, like timers, cronjobs, set. They were too lazy to go back and put in the requirement that all units have a user clause. And too proud to admit they didn't think that far ahead.

    --
    No, you are mistaken. I've always had this sig.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by Azuma Hazuki on Tuesday July 04 2017, @02:00AM (3 children)

    by Azuma Hazuki (5086) Subscriber Badge on Tuesday July 04 2017, @02:00AM (#534637) Journal

    Screw this. I found an Arch-OpenRC iso and am going to install that, and if systemd ever becomes part of the kernel either literally or de facto, I'm moving onto *BSD.

    The links below mentioning the politics of Poettering-itis are eye-opening and sobering, and *once again* we can't have nice things because greed. Perkele!

    --
    I am "that girl" your mother warned you about...
    • (Score: 4, Insightful) by Thexalon on Tuesday July 04 2017, @02:09AM (2 children)

      by Thexalon (636) on Tuesday July 04 2017, @02:09AM (#534642)

      Slackware, Devuan, and Gentoo are all options for distros that have stayed mercifully free of Poettering's persistent pitfalls.

      --
      The only thing that stops a bad guy with a compiler is a good guy with a compiler.
      • (Score: 0) by Anonymous Coward on Tuesday July 04 2017, @02:22PM (1 child)

        by Anonymous Coward on Tuesday July 04 2017, @02:22PM (#534798)

        Well...they do all have pulseaudio by default at this point. But he's been off the project long enough now that it's not as bad as it was for a long time. Doesn't necessarily mean the Slackware community is all too pleased about it.

        • (Score: 0) by Anonymous Coward on Saturday July 15 2017, @03:31PM

          by Anonymous Coward on Saturday July 15 2017, @03:31PM (#539556)

          Mostly because Bluez have decided to hard depend on PA for their audio IO needs...

  • (Score: 0) by Anonymous Coward on Tuesday July 04 2017, @10:26AM

    by Anonymous Coward on Tuesday July 04 2017, @10:26AM (#534752)

    Lazy developers of systemd is my guess. They didn't want to have to have a user = clause in every friggin unit.

    Even then, having "User = " is different from not having an "User =" clause at all. While defaulting no user line to root is a bad idea, defaulting an *invalid* user line to root is a terrible idea.

  • (Score: 0) by Anonymous Coward on Tuesday July 04 2017, @10:42AM

    by Anonymous Coward on Tuesday July 04 2017, @10:42AM (#534758)

    They didn't want to have to have a user = clause in every friggin unit.

    That's doesn't explain it. We are not talking about the case of no user= clause, we are talking about the user= clause exists, but the value is not acceptable to systemd.

    Which makes it even worse, because what's acceptable to systemd is not the same as what's acceptable to the rest of the system. You can have a completely valid user named 0day, and if the admin doesn't know that this user is not acceptable to systemd, he will put the user name in the user= clause just as he would any other valid user. But because systemd doesn't follow any standards, and considers 0day an invalid user name, AND systemd is apparently written by someone who considers ON ERROR RESUME NEXT to be a fully valid way to write code, we end up with root even though a different user was specified.

    Allowing the valid username "0day" would be a better solution. Declaring the unit file broken and refusing to start the service would be a better solution.

    From a security point of view, even crashing the system would be a better solution.