1. 56

Via https://twitter.com/diodesign/status/881297275070234624

  1.  

  2. 26
    1. [Comment removed by author]

      1. 21

        Apparently, if the value begins with a digit, it attempts to parse it as a UID; if that fails, it logs and ignores the directive (thus defaulting to running the unit as root). If the value doesn’t begin with a digit, it’s treated as a username, and if the lookup fails, the whole unit fails to start.

        The scope of vulnerability here is fairly limited (you’d need the ability to provide arbitrary units to the PID-1 systemd instance, which you could use to do much worse things than non-silently and obscurely run the unit as root), but the design is so bad it makes my eyes cross. Syntactically-correct-but-invalid is more fatal than syntactically-incorrect? Soldiering on despite detected parse errors? It’s this sort of thing more than any particular bug or misfeature (not that there aren’t plenty of the latter) that triggers my ire for systemd. Why are these people designing software at all, let alone essential system software?

        1. 15

          An example of somewhere where it would matter a lot: You, as the sysadmin, have a service you want to run as a specific user. That service has a remote code execution vulnerability. This bug can cause that service to silently be ran as root instead of a restricted user.

          1. 7

            Yeah, it may not be much on its own, but anything which allows the possibility of something silently running at a higher-than-expected privilege level should be considered a security concern.

      2. 9

        It is not as bad as the title suggests: if you specify a UserID in your unit file that starts with a digit, systemd will ignore the UserID option and run the process as managed by systemd as root.

        I do wonder if this works when using systemd as cron replacement, i.e. systemd.timer(5) from your user account. That would be a neat vulnerability.

        1. 23

          It is not as bad as the title suggests: if you specify a UserID in your unit file that starts with a digit, systemd will ignore the UserID option and run the process as managed by systemd as root.

          A fail-open approach to system security still sounds pretty terrible, honestly. Typos in service configuration shouldn’t end in root privileges.

          1. 2

            I mean, that’s how it usually works. At least, sysv init you’d have to manually change the user from root if you want that, otherwise your process runs as root.

            I think if you wanted to avoid this kind of thing you’d have to require that the user option be always specified or use some default very low permissions user that probably won’t work. Which is fine for me, but I assume the authors didn’t want that.

            1. 3

              True, it’s a potential gotcha in sysvinit scripts as well. Either you need to error out when your su fails rather than continuing to run the script, or use a construct like su -c that won’t run the command if it’s not able to change user.

              The systemd version is a more subtle gotcha though, because it looks more declarative. The su approach in a sysvinit script is obviously just an imperative command, so it’s clearer that you need to defensively program around it. It’s not as obvious that an invalid user in a systemd file is effectively the same as running an invalid su, ignoring the error, and then continuing to run the rest of the script.

              1. 2

                I mean, that’s how it usually works. At least, sysv init you’d have to manually change the user from root if you want that, otherwise your process runs as root.

                Well, yeah. Of course, repeating SysV’s security flaws when you should know better by now strikes me as a massive design mistake in a SysV successor.

                But this isn’t exactly the first wildly-questionable decision re: security we’ve seen from SystemD, so maybe I shouldn’t be surprised.

          2. 2

            when he says ‘we’, does he mean ‘I’ ?