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 Thexalon on Tuesday July 04 2017, @02:24AM (8 children)

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

    I'll put it this way: It's always been clear to me that whatever Poettering's motivations, they weren't technical in nature. If they had been technical in nature, he wouldn't have gone out of his way to make his stuff not work with what already existed.

    Take logging, for instance. Let's say I wanted to introduce a new binary logging format for some reason, that I wanted all system-level software to use. Should I:
    A. Write something that (1) is a drop-in compatible replacement with existing widely-used logging tools like good old syslog that converts the input to the binary format and writes that to the file, (2) converts that binary file into the text formats we all know already with vim plugins and such so we inflict as little pain as possible on existing log-processing tools, and (3) has additional bells and whistles and gongs that makes this conversion all worth it.
    B. Write something that uses a different kind of interface than all of the existing tools use, and demand that every daemon be changed to do things my way.
    Poettering took option B, and there was no obvious technical reason for him doing so.

    One other aspect of this particular bug that jumps out at me is that Poettering seems to be indifferent at best towards the concept of a "user" in Posix-based systems: He doesn't believe in sudo, su, or any similar kinds of tools. If you don't have the concept of user-based privileges, then privilege escalation bugs don't seem like a big deal, I guess. My guess is he runs his own boxes as root, which is why he doesn't notice the issues that causes or the reasons why not giving everybody root is a very good idea.

    --
    The only thing that stops a bad guy with a compiler is a good guy with a compiler.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

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

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

    It occurs to me that Poettering's approach is basically how a Windows user would have written Linux programs. That is not a nice thought.

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

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

      It occurs to me that Poettering's approach is basically how a Windows ME user would have written Linux programs.

      FTFY. After that point, Windows had concepts like users, privileges & permissions, and a whole lot of other very useful concepts that Unix had had for decades, but Poettering doesn't seem to care for.

      --
      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, @05:49AM

        by Anonymous Coward on Tuesday July 04 2017, @05:49AM (#534691)

        FTFY. After that point, Windows had concepts like users, privileges & permissions, and a whole lot of other very useful concepts that Unix had had for decades..

        That may be true, but I still have to run (¹allegedly) current commercial code on Win7 boxes which requires admin rights to work, try them as normal user? all sorts of weird BS happens or it just fails to run.

        I still occasionally get 'bitten' by this BS with the occasional weird edge-case 'works-as-admin-but-not-as-user' snafus with Windows software, and we're not talking about just 'cheap' software having this problem, one of our expensive CAM packages has only just (just, in this case being in the past two years) gotten to the point where it no longer requires to be run as an admin user to work properly and it now runs without issue as a normal user, whereas, in the past, running it as a normal user meant that it might work 90% of the time, but then horribly fail on some operations...

        The point is, while Windows does 'understand' these concepts, there's a hell of a lot of reused Windows code which doesn't, and programmers out there who still don't.

        ..but Poettering doesn't seem to care for.

        He is, indeed one of the Knights who say NIH!

        ¹ I say 'allegedly', I'm of the opinion that the code is exactly the same and only the version number has been changed just to make it look as if the damnable thing is still being developed..

    • (Score: 2) by Runaway1956 on Tuesday July 04 2017, @07:26AM (1 child)

      by Runaway1956 (2926) Subscriber Badge on Tuesday July 04 2017, @07:26AM (#534710) Homepage Journal

      Mmmm. That's scary to even think about. Your Windows user is likely to import DLL files for use as libraries. And, Microsoft would probably let him get away with it because embrace, extend, extinguish. Never mind that DLL's wreck anything or everything in existing libraries.

      --
      "no more than 8 bullets in a round" - Joe Biden
      • (Score: 2) by Azuma Hazuki on Tuesday July 04 2017, @07:53AM

        by Azuma Hazuki (5086) Subscriber Badge on Tuesday July 04 2017, @07:53AM (#534719) Journal

        A DLL is the Windows equivalent of a .so and in theory should be no more or less harmful all else being equal. We're long past "DLL Hell" aren't we? Now the problem is what's *in* the .dll files...this Linux Subsystem for Windows isn't even a solution looking for a problem, it's a shambling undead mess given an assassination mission.

        --
        I am "that girl" your mother warned you about...
  • (Score: 2) by kaszz on Tuesday July 04 2017, @03:13AM

    by kaszz (4211) on Tuesday July 04 2017, @03:13AM (#534658) Journal

    Found another good post:
    https://it.slashdot.org/comments.pl?sid=10813029&cid=54733555 [slashdot.org]

    Simply, the problem is more complex than what they postulated and their solution, while working on most of it, breaks on the edge cases, which are... more than a bit numerous. And sometimes quite fundamental.

    And so, instead of thinking up a different solution, that is more correct, they begin patching the caveats and edge cases in a half-assed manner one by one, building that brittle, baroque, juvenile and overly complex tower on top of the neat core. And as more and more things start falling through the cracks, they keep adding bandaids.

  • (Score: 1, Interesting) by Anonymous Coward on Tuesday July 04 2017, @03:16AM (1 child)

    by Anonymous Coward on Tuesday July 04 2017, @03:16AM (#534660)

    Text logs are fine, just add another file with pointers or any other helper metadata new tools can need. Similar to BSD vipw and pwd_mkdb handling and checking text and binary files so they always valid, easily "grepable" (text ones) or fast via API/ABI (bin ones), in sync and simple to recover if something goes wrong.

    Bonus: the text log files can be set to append only (see chattr(1)). Then set owner to something except the logger process, and the group to logger process so it can writeappend. Magic: now modification or deletion of past logs needs root or whatever owner the file has, so comprossing the logger is not enough.

    But you know, defense in depth is hard to grok. Another level would be shipping copies of logs to a different machine, and both local and remote would still use this append-only trick. But for standalone machines the append-only method would be an improvement.

    • (Score: 2) by Thexalon on Tuesday July 04 2017, @05:27PM

      by Thexalon (636) on Tuesday July 04 2017, @05:27PM (#534846)

      The point is, even if you accept that journald is useful (an open question), they're doing it wrong.

      --
      The only thing that stops a bad guy with a compiler is a good guy with a compiler.