Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Open Source Operating Systems Security Unix Linux Technology

Flaw In Sudo Enables Non-Privileged Users To Run Commands As Root (thehackernews.com) 139

Posted by BeauHD from the Su-doh dept.
exomondo shares a report from The Hacker News: A vulnerability has been discovered in Sudo -- one of the most important, powerful, and commonly used utilities that comes as a core command installed on almost every UNIX and Linux-based operating system. The vulnerability in question is a sudo security policy bypass issue that could allow a malicious user or a program to execute arbitrary commands as root on a targeted Linux system even when the "sudoers configuration" explicitly disallows the root access. Sudo, stands for "superuser do," is a system command that allows a user to run applications or commands with the privileges of a different user without switching environments -- most often, for running commands as the root user.

The vulnerability, tracked as CVE-2019-14287 and discovered by Joe Vennix of Apple Information Security, is more concerning because the sudo utility has been designed to let users use their own login password to execute commands as a different user without requiring their password. What's more interesting is that this flaw can be exploited by an attacker to run commands as root just by specifying the user ID "-1" or "4294967295." That's because the function which converts user id into its username incorrectly treats -1, or its unsigned equivalent 4294967295, as 0, which is always the user ID of root user. The vulnerability affects all Sudo versions prior to the latest released version 1.8.28, which has been released today.
This discussion has been archived. No new comments can be posted.

Flaw In Sudo Enables Non-Privileged Users To Run Commands As Root More

Flaw In Sudo Enables Non-Privileged Users To Run Commands As Root

Comments Filter:

  • damn, who told on us (Score:5, Funny)

    by 2TecTom ( 311314 ) on Monday October 14, 2019 @06:31PM (#59307486) Homepage Journal

    ... a few more days and all your bases belong to us ...

  • Not many systems vulnerable (Score:5, Informative)

    by whoever57 ( 658626 ) on Monday October 14, 2019 @06:44PM (#59307520) Journal

    This requires that the user be set up in /etc/sudoers to be allowed to run commands as another non-root user.

    That's a fairly unusual configuration.

    • Re: (Score:2)

      by mveloso ( 325617 )

      In corporate environments it's not as unusual as you'd think.

      • In corporate environments it's not as unusual as you'd think.

        I think you're wrong.

        It's pretty common in corporate environments to give some users (actually, groups) the ability to run certain commands as a certain other user, but that's not a scenario that would allow this bug to be exploited. For this to work, you have to have some users with the ability to run commands as any user but root. I can't think of any situation in which it would make sense to allow someone to impersonate any other user or non-root system daemon, but not be root. You would be giving t

        • Re: (Score:2)

          by jabuzz ( 182671 )

          You might want to give a DBA the ability to restart the database so they get access as mysql or postgres user which would allow them to do that without being able to generally be root on the machine.

          However this has got to be a pretty rare scenario.

          • Re: (Score:2)

            by Chrisq ( 894406 )

            You might want to give a DBA the ability to restart the database so they get access as mysql or postgres user which would allow them to do that without being able to generally be root on the machine.

            However this has got to be a pretty rare scenario.

            Then you'd give them sudo access to "dbadmin", "postgress" or a similar user, not everyone but root

        • Well... no.

          You're right in a well set up environment, but you can rest assured that lazy configuration trumps security. Instead of creating 10 different groups for 10 different sudo scenarios, such a "you can impersonate everyone but root" rule would probably satisfy most compliance requirements and mean little work for the administrators when setting up rules.

          It should be rare, I give you that. But I highly doubt that it is.

          • such a "you can impersonate everyone but root" rule would probably satisfy most compliance requirements

            Only if the compliance auditor is an idiot... okay, I concede your point.

      • Re: (Score:2)

        by pnutjam ( 523990 )
        Who among us has not walked into a corporate environment and had to pick your jaw up off the floor when you see what passes for security.

        Outside heavily regulated environments, and even many of those seem to work the loopholes.

    • This requires that the user be set up in /etc/sudoers to be allowed to run commands as another non-root user.
      That's a fairly unusual configuration.

      Unusual? ... what?

      Is it unusual to run services or own files as something other than root?

      So would it be unusual to let non-admins run commands as that service account, to administer the service without being given root to insecure things like less and vi and ... well basically everything is unsafe for untrusted users to run as root.

      It would be unusual for multiple people to be logged into a Linux laptop, but that has shit to do with the severity of this on managed unix servers that have actual users.

      • It's very common to have a "service account" than can run specific privileged operations. This especially includes backup operations and filesystem commands.

        • Re: (Score:3)

          by Rashkae ( 59673 )

          Good thing thing this flaw doesn't affect them then.

          This needs a sudo user who can run as *any* user other than root, (so not privileged, or wasn't, until this flaw was found.)

          The only example I can think of is someone who runs tech support on systems with multiple users, who has to execute commands as the user they are trying to assist...something like virtual machine hosts for cloud vm's? (linode, hostgator, etc.)

          • Re: (Score:2)

            by WallyL ( 4154209 )

            The only example I can think of is someone who runs tech support on systems with multiple users, who has to execute commands as the user they are trying to assist...something like virtual machine hosts for cloud vm's? (linode, hostgator, etc.)

            Adding on to your comment, I think that SELinux can throw a wrench into your example. Switching users doesn't necessarily switch contexts so even if you're now "that user," you're still not "that user." It doesn't quite make sense, but I've seen it happen that way.

      • Is it common (or even possible) to have service accounts with userid 4294967295? Because that's what's required. If you let someone run as 4294967295, they can also run as root. Because 4294967295 is 2^32 - 1.

        • Nice.

          It would have been great if the summary or linked article wasn't written specifically to scare the shit out of people, and we didn't then have to scroll through a page of comments defending a non-existent but objectively bad situation where sudo to _another_ user was affected.

          (ALL, !root) or I guess (4294967295) maybe?
          If that's what it really takes, that should be rare, I hope anyway.

    • Re: (Score:2)

      by gweihir ( 88907 )

      It is fairly unusual. Also, quite a few people will still just su to root and never do any sudo config at all.

      • "su to root" requires a local root password. AWS hosts built from almost any published host image enables sudo for the "ec2-user" addount, or perhaps "centos" account, and has a locked root password.

        • Re: (Score:2)

          by gweihir ( 88907 )

          I never understood this stupidity. Giving root functionality to normal users via sudo is worse than using proper root access.
          Anyways, AWS host images are not the standard for Unix system configurations, even if apparently some people know nothing else.

          • Re: (Score:2)

            by pnutjam ( 523990 )
            What is "proper root access"? Sudo lets me give a user access to specific commands or scripts I control. As long as they don't have rights to modify the script, I can let them do as much or as little as I like.

            • Re: (Score:2)

              by gweihir ( 88907 )

              And as soon as you screw up, they can become root.

              "Proper" root access is logging in as user root.

              • Re: (Score:2)

                by pnutjam ( 523990 )
                Great for hobby systems, but if security is an issue it doesn't work.

                • Re: (Score:2)

                  by gweihir ( 88907 )

                  It does work. I have seen it done this way on high-criticality systems. Of course, on these systems everything gets logged, you have to state a reason for the root-log in before being allowed to and on same machines you need an open support ticket assigned to you and the activity logs actually get reviewed.

                  My point is that "sudo" is not really a good idea. If you need users to do root things without root login, use the suid bit. Otherwise have a trusted administrator do things as root.

    • Re: (Score:2)

      by mysidia ( 191772 )

      The headline is bogus... it should be allows "Privileged users to run commands as root".

      If you have been blessed with the power to run commands as ANY user you want, then you are still specially privileged, even though you are not fully privileged.

      Its a rare/unusual configuration to say (all, !root) --- the people using this configuration on their systems should probably KNOW there are going to exist some ways that access can be abused to ultimately circumvent the intended !root rule - If not withi

  • The "su" in sudo stands for switch user or substitute user and not superuser.

    • Re:sudo does not stand for superuser do (Score:5, Informative)

      by exomondo ( 1725132 ) on Monday October 14, 2019 @08:46PM (#59307852)

      The "su" in sudo stands for switch user or substitute user and not superuser.

      From the original V5 unix code:
      /* su -- become super-user */
      su.c [tuhs.org]

      You can also look at the sudo.c code from Todd Miller back in 1993:
      sudo version 1.1 allows users to execute commands as root
      sudo.c [www.sudo.ws]

      Indeed options were added later to be able to choose different users so redefining the "su" to mean switch user or substitute user may make more sense now but certainly it was originally "super-user".

      • Re: (Score:2, Informative)

        by Anonymous Coward

        And in version 7 Unix (1979, long before 1993) the source code clearly shows that su could switch to any valid user. Therefore I don't think it's fair to that the options were "added later" (the options for su to accept any user were there long before sudo became a standard command)

        https://minnie.tuhs.org/cgi-bi... [tuhs.org]

        • Re:sudo does not stand for superuser do (Score:5, Informative)

          by exomondo ( 1725132 ) on Tuesday October 15, 2019 @01:30AM (#59308280)

          And in version 7 Unix (1979, long before 1993) the source code clearly shows that su could switch to any valid user.

          Yes, like I said that was added later, version 7 came after version 5. See su.c [tuhs.org]. The original code for su was to elevate to super-user only (see code in version 5), later in version 7 the ability to switch to any user was added.

          So su was super-user with others added later. Next we can look at the history of sudo the same thing happened, in 1993 the code [www.sudo.ws] was purely for super-user then later the ability to switch to different users was added.

  • Yet another C-based security bug (Score:3, Funny)

    by aberglas ( 991072 ) on Monday October 14, 2019 @07:08PM (#59307584)

    Almost certainly the result of an integer overflow. Any decent language (like Visual Basic!) would trap that and simply fail fast. But not C.,

    And no, it does not slow things down with a proper programming language because the traps happen in hardware. No overhead.

    • Re: (Score:2)

      by Megane ( 129182 )
      More likely it is the result of a "return -1 for errors" paradigm combined with the "ignore errors that don't cause a crash" paradigm. Those are both common with C but not exclusive to C.
    • The problem is not due to C, it's due to a bug made by a C programmer.
    • Yeah ... Let's rewrite the Linux kernel and all of userspace in Visual Basic. We can have software "experts" like you do it. It will be glorious I'm sure.

    • And no, it does not slow things down with a proper programming language because the traps happen in hardware. No overhead.

      Um... No. Sorry, but the trap doesn't happen in hardware. The hardware sets a flag, but does not act on it unless you specifically add code to check it and do something if it is set.

      • Sadly, that has become true.

        Earlier systems like MIPS and VAX had overflow traps. But the popularity of C has crippled hardware architectures, and this is one example of that.

        Still, most of the time performance is not critical. So the extra instruction does not matter. And when performace is critical use the non-trapping operator, maybe +.

        That said, I think Risk V does not even have an overflow bit. So it looks like C is winning.

        Good for us software engineers, I suppose. Keeps the work up.

        • Depends on the instruction I suppose, and I shouldnâ(TM)t have assumed we were talking about intel/amd architecture, but doing a trap even in hardware automatically would severely complicate doing multi word arithmetic where overflow/carry is not an exceptional circumstance and likely performance. And these things apply not only to C, but also assembly and machine language.

    • I think you found a way to slow Linux down to the point where Windows would look like a viable alternative.

  • Sudon't you want me baby (Score:4, Funny)

    by Provocateur ( 133110 ) <shedied@gmai[ ]om ['l.c' in gap]> on Monday October 14, 2019 @07:23PM (#59307628) Homepage

    I was working as a waitress in a cocktail bar
    That much is true

    Apologies in advance if the tune is stuck in your head all day. Happy 50th Unix =)

    • It's much too late to find
      You think you've changed your mind
      You'd better change it back or we will both be sorry

      I hate you. I was just about to forget that damn song!

  • Sususudio is a hacker. Just say the word is the password. It all makes sense now.

  • This sounds like a backdoor. Is there enough revision history available to tell who was the 1st person to check in that line of code? I do understand that this may have to go back over many years and across a number of SCMs. So the answer may be a "no". But is it a "no"? It's hard to not suspect malice in this case.

    • Yes, the revision history is there. It's been like that ever since sudo started letting you specify a user other than "root" to sudo to. I can tell you who introduced that code - Todd Miller has been writing almost all of the sudo code since 1993 or so. He committed the code that garp@opustel.com wrote to allow sudo to be used to switch to a user other than root.
      https://www.sudo.ws/repos/sudo... [www.sudo.ws]

      It would be the worst idea for a backdoor ever. Sudo is normally used to let someone run a command as root. F

  • Present in all prior versions of sudo! That's an extremely old vulnerability. It's slightly startling that such a glaring flaw could slip by unnoticed for so long. Is it possible that this was a non-issue on old UNIX kernels and only later became a liability on Linux?

    • Re: (Score:2)

      by skids ( 119237 )

      I'm too sleepy to analyze code but reading the patch there's a lot of integer type size wrangling, so perhaps on some old enough systems one of their internal types was 32 bit and is now 64. So possibly. On extremely old systems.

    • About as "glaring" as starlight reflected off of a bed of moss. As in, you can't even see it.

      • Re: (Score:2)

        by Chromal ( 56550 )
        Not bounds checking something like UID in a program that can escalate system privileges is far more glaring that a PHP cross-site-scripting vulnerability, and those are considered elementary.

    • Well, glaring... the vulnerability is very specific, it requires a very special kind of configuration ("may run anything as anyone except root") AND finding the associated exploit.

      • Re: (Score:2)

        by Chromal ( 56550 )
        Yeah, I agree the conditions for exploitation are unusual and infrequently used. I can only think of one time in my entire career I've implemented that, though ironically when used it means a site is taking extra precaution to limit access to the superuser and grant the minimum privilege needed to accomplish a task.
  • I tried it and it doesn't work.

    • sudo -u#-1 su

      Will work if your system has not been updated, won't work if it has.

      But in every system I've ever administered, it does exactly the same thing as sudo su, so it is not relevant to most people.

  • Root being UID zero was a mistake. (Score:3)

    by Kaenneth ( 82978 ) on Monday October 14, 2019 @10:01PM (#59307994) Journal

    Linux using ID 0 as root always bothered me, since there are so many ways to get to zero. It's as simple as just not initializing the UID variable from empty memory. Or passing an invalid string to atoi(). Or 'UID-=UID;' or any number of underhanded/accidental ways.

    root UID should have been randomly (from an admin configured range) per-system on install, with an easy to use/detect 'getRootUID' function so it would be near impossible to 'accidentally' give root access like this, and could be easily tracked in source code.

  • Reminds me of a joke... (Score:3)

    by The123king ( 2395060 ) on Tuesday October 15, 2019 @06:41AM (#59308678)
    "A software QA engineer walks into a bar. He orders a beer. Orders 0 beers. Orders 99999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd.

    First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone."

  • ...in the latest version of systemd.

Slashdot Top Deals

To stay youthful, stay useful.

Close