back to article Oh ****... Sudo has a 'make anyone root' bug that needs to be patched – if you're unlucky enough to enable pwfeedback

Sudo, a standard tool on Unix-y operating systems that lets select users run some or all commands as root, can be exploited to give superpowers to any logged-in user – if deployed with a non-default configuration. This security hole, discovered by Joe Vennix at Apple Information Security, is only active if the pwfeedback …

  1. Jou (Mxyzptlk) Silver badge

    SUDO and +s is a design weakness

    It was right decades ago, but its time is up...

    1. Anonymous Coward
      Anonymous Coward

      Re: SUDO and +s is a design weakness

      Quite right, let's have everyone log in directly as root instead. What could possibly go wrong.

      1. Jou (Mxyzptlk) Silver badge

        Re: SUDO and +s is a design weakness

        Oh, so you want DOS back?

        1. Anonymous Coward
          Anonymous Coward

          @Jou - Re: SUDO and +s is a design weakness

          Oh, dear! Where do you think Microsoft got the idea for Run as... ? Let's not be silly, shall we ?

          Here, have my down vote!

          1. phuzz Silver badge

            Re: @Jou - SUDO and +s is a design weakness

            And UAC, although that's closer to gtksudo etc. I suppose.

          2. Jou (Mxyzptlk) Silver badge

            Re: @Jou - SUDO and +s is a design weakness

            Just for completenss: Microsoft implemented RBAC on a higher scale with Windows 8 / Server 2012, though it is possible since Windows NT 4.0 (could not test NT 3.x). But they kept UAC for a good reason, and I recommend setting it to the highest level. So it has both. It is time for *ix to have RBAC available on a broad scale, not just a hand full distros.

            Doesn't help if it RBAC is not used though - no matter which OS.

      2. Doctor Syntax Silver badge

        Re: SUDO and +s is a design weakness

        No, you let only those entitled to log in as root do so. Part of the problem is that although early Unix had multiple user IDs for different tasks these all got handed back to root eventually. Why, for instance, couldn't a specific non-root user have rights over installing S/W in /usr/local?

        1. jtaylor

          Re: SUDO and +s is a design weakness

          "Why, for instance, couldn't a specific non-root user have rights over installing S/W in /usr/local?"

          Just make a group that contains the users you want to be able to write to /usr/local, and chown the directory to that group. I don't think Linux can handle nested groups, which is a nuisance.

          Of course, that basically gives the person root access because they can replace parts of the OS with Folger's Crystals that will then be used by everyone else, including the root user.

          I prefer that the Specific Non-Root User install software in a subdirectory of their home directory. If they want to let others use the software, they can set permissions to give those others read+execute rights. Best of all, none of this requires special permission from the server admin. If compiling from source code, just build it in the location you choose. RPM packages use an environment variable to make it very easy to do exactly this. I assume that Debian packages have similar.

          1. Robert Carnegie Silver badge

            Re: SUDO and +s is a design weakness

            Even a BOFH should do most things with an account other than root. I don't think we're asking the janitor to install applications - though if they're reliable then why not - but to have different hats, as it were, representing different tasks.

            Of course, to swap hat momentarily, you use sudo (or su). Whoops!

        2. doublelayer Silver badge

          Re: SUDO and +s is a design weakness

          If you want, you can make it very easy for nonroot users to do lots of things, including adding restrictions to exactly which users can do those things. The utility of sudo is that, should you want to change what they can do, it's a lot easier. Say you do want to allow some users to modify /usr/local, but not to have other root permissions. We're using this as an example, but in reality that would be a terrible thing to let them do as that would provide them a great deal of access to mess up everything.

          If you do it the old way, by adding them to a group and assigning /usr/local to that group, it's easy. Anyone in the group gets the access you set. If you want to remove that permission, you kick the user out of the group. Easy. Unless you left the company and I'm running the system now, because I don't necessarily know all your groups and what you let them do. You've probably documented it somewhere, but that might be for some systems but not others, or somebody lost your documentation, etc. So now there are users whose access I can't cut off because I don't know it exists. I could do a global check of the filesystem to see if there are any unusual owners or groups, and after I find this first one I probably will, but it's not at all something a new admin would be expecting.

          There's another classic way to expose functionality to users: a program running as root that receives user commands. The program itself has root capabilities, but the user doesn't. They issue the command they'd like, and that program determines if they have the rights to execute that command and does so. This works well too, and it lets you introduce even finer controls on what someone can do. So, for example, you can block them from installing a compromised copy of a utility over an old one, but continue to allow them to write new files in there. This is harder for the user, as they'll have to learn how your program works. It's also harder for you, because you'll have to write the program. It's a little easier for me, because your program will either have to have a server component which gets started on boot (thus I can easily see it) or at least it'd be in a directory on a path. Of course, if I don't have source code for this program, my life is really annoying.

          Now, we have sudo. Sudo is limited, and it can have flaws. No question about that. But it allows you to relatively easily define who is allowed to do what. It can require their password, so even if someone gets access to an open terminal of theirs or one of their SSH private keys, they can't elevate easily. Your program could do that, but only by replicating sudo's functionality to a certain degree, and the owner and group solution doesn't give you that option at all. It's easier for the user because the commands are nearly always the same. It's much easier for me. If I want to know who has special access, specifically what, and what they do with it, I can find all of that in the sudo configuration files and logs. It's one place, and it's now common enough that it's a typical place to check when administrating a new system.

          1. Loyal Commenter Silver badge

            Re: SUDO and +s is a design weakness

            ...a program running as root that receives user commands...

            This is also a potential security hole; you'd better make sure your program has no flaws, or buffer overflow exploits, and if it allows a user to run certain other commands with root privileges, then those programs themselves have no such flaws.

            By doing this via a common well-recognised route (sudo), you reduce that attack surface to only the vulnerabilities in sudo itself. Admittedly, in cases such as this, if sudo has a buffer overflow flaw, then you've got a problem. However, a known flaw (that gets patched, hopefully very quickly) is better than a hundred unknown flaws that may be getting exploited for years without you knowing anything about them.

            Security is hard. Rolling your own is almost never the right solution. I am, frankly, astounded that something as basic and ubiquitous as sudo has such a flaw, not least because I would have expected it not to have changed substantially in many years. Whoever is responsible for doing that particular code-review needs a spanking, as does whoever is responsible for doing a security audit of the build. After all, a root escalation exploit in a tool used for controlled root escalation is an obvious place to look for well known flaws such as buffer overflows.

        3. Anonymous Coward
          Anonymous Coward

          Re: SUDO and +s is a design weakness

          Because arbitrarily installing software (even in low privilege areas) is a malware slingers wet dream.

          Sysadmins need to lock down sudo rights. It's not hard.


          It's all in there.

      3. Anonymous Coward
        Anonymous Coward

        Re: SUDO and +s is a design weakness

        Most *IX flavors, and even Linux, have supported RBAC for a long time. It’s just that people use sudo because they’re lazy and setting up RBAC correctly takes effort.

        1. donk1

          Re: SUDO and +s is a design weakness


          - RBAC is not configured the same way on all platforms

          - RBAC may have different capabilities on each platform/version

          - Having to configure a person into different RBAC 'groups' on each platform is inefficient/error prone or requires more automation to be built/tested/patched.

          - Producing a unifired audit trail across all RBAC platforms is probably either not feasible or painful.

          - Not sure how well automation tools support RBAC configuration across platforms

          1. Anonymous Coward
            Anonymous Coward

            Re: SUDO and +s is a design weakness

            And sudo has none of those issues? Seriously? If you use bog standard plain sudoers setups, then sure, maybe you have a point. Once you start throwing different sudo plugins (such as this one!) into it or fancy things like AD groups or what not, I'm sorry, your point starts to become less valid. The ONLY point left is that there's probably already some sudo template for your automation system that you can steal and hope that it pretty much does the right thing.

            Lack of templates sounds more like an issue with your automation/testing platform and not a problem with RBAC itself. Any decent system out there can already handle the platform differences for you, just like it does for everything else (eg, different shells).

        2. Anonymous Coward

          Re: SUDO and +s is a design weakness

          Most *IX flavors, and even Linux, have supported RBAC for a long time. It’s just that people use sudo because they’re lazy and setting up RBAC correctly takes effort.

          You write this as if laziness is a bad thing. Some people describe getting the desired result with the minimum of effort as being lazy. Others call it achieving maximum productivity.

          1. Anonymous Coward
            Anonymous Coward

            Re: SUDO and +s is a design weakness

            It depends. If you can do lazy AND correct, then awesome, that's ideal!

            If the two choices are lazy OR correct, then in the majority of the time, lazy is wrong answer. I myself am guilty of going "It's just temporary, I'll redo it the correct way later when I have time!". Of course, that almost never happens, unless something forces your hand. It's the exact same reason most people don't run daemons in proper chroot jails even though chroot has been around for so long.

            Look at the multitude of sudo security issues over the years and then tell me with a straight face that all of that was worth it. There is no reason that a distro couldn't ship a decent default RBAC setup and tools to make it easier for the users to modify them. If RHEL can setup &#$ SELinux "properly" out of the box, which is almost infinitely more complex, then there's just simply no excuse at this point.

          2. Anonymous Coward
            Anonymous Coward

            Re: SUDO and +s is a design weakness

            It's not lazy, it's least administrative effort.

      4. Robert Carnegie Silver badge

        Re: SUDO and +s is a design weakness

        telnet localhost, surely? :-)

        (a more innocent time)

    2. Cem Ayin

      Re: SUDO and +s is a design weakness

      "It was right decades ago, but its time is up..."

      I partially concur: the suid-mechanism is not exactly one of the strong design points of Unix and basing a central component of user authentication and authorization on it is suboptimal to say the least - particularly if said component is a rather complex program written in C...

      One of the few things that Windows does indeed better than Unix is that admin privileges do not depend on a well known UID but on group membership to begin with, which eliminates the need of contraptions like sudo just in order to avoid shared admin passwords.

      Making things worse, sudo tries to be a poor man's RBAC and makes a rather poor job of it too.

      (Note that the whole concept of RBAC, while being a good idea in principle, is totally flawed if it is not fully supported by the kernel's security reference monitor from ground up. E.g. the idea of allowing a user to install random software in system locations without conferring additional privileges is a complete fallacy on Unix: you'd need MAC-based security plus labels on each file a user creates /plus/ a mechanism in the SRM to ensure that a program installed by user X can /never/ run with any privileges X did not have at the time of the program file's creation - good luck with that one.)

      1. nijam Silver badge

        Re: SUDO and +s is a design weakness

        ... admin privileges do not depend on a well known UID but on group membership ...

        That's only a cosmetic difference. Sudo itself can use group-based permissions, though whether you gain anything is unclear. I know, from years of involvement, that Windows' group-based permissions also degenerate into an unholy mess as soon as you need anything non-trivial.

  2. Bronek Kozicki

    buffer overflow found in sudo

    That's a better hair-raising title. Well, at least personally to me.

    1. diodesign (Written by Reg staff) Silver badge

      Better title

      Yeah, if it was the default configuration and in the main distros.

      If we focus on the bug type, people will complain we're overblowing it. If we focus on the scope people will complain we're downplaying it.


      1. Loyal Commenter Silver badge

        Re: Better title

        I'd argue that if the flaw is in the source (even if not the default configuration) then the flaw is in the compiled code. Whether it's turned on or off is largely moot, the alarming thing is that such a flaw exists in sudo.

        If by "configuration", what is being talked about is whether the code in question is compiled in or not (i.e. due to an #IFDEF section), then it's slightly less alarming, although still alarming that such flawed code should make its way into the "official" source.

        I am assuming here that such things are tightly controlled, and someone somewhere is responsible for maintaining an "official" source for the sudo command. Presumably, it's low-level enough to be distributed with the kernel (I've never dug into the innards of *nix enough to know, TBH, I don't fancy losing myself in that particular time sink). I would guess that various distros don't go around rolling their own forks of sudo for shits and giggles, because frankly, as a security practice, that would smell very bad.

        1. katrinab Silver badge

          Re: Better title

          In FreeBSD it is in the ports collection and not installed by default.

          In Debian, it looks like it is in their package repository and not installed if you select the minimum install option.

          1. Loyal Commenter Silver badge

            Re: Better title

            Seems sensible. Presumably both of those distros are including a version of sudo that comes from the same verified source (if not the same version). Wikipedia tells me it is maintained by Todd Miller, but doesn't reveal whether it is a team effort, or entirely the fault work of one man...

            1. John Brown (no body) Silver badge

              Re: Better title

              I take issue with referring to FreeBSD as a "distro", since in this context "distro" almost exclusively refers to various Linux incarnations and FreeBSD is not Linux :-p

              Having said that. sudo in FreeBSD just got patched too!

              1. Loyal Commenter Silver badge

                Re: Better title

                I consider myself suitable chastened.

                Of course, I would expect sudo is available in many if not all types of *nix, not just the penguin-flavoured ones. I'm assuming it's the same in all of these, although I will confess to not knowing much about the deep innards of various OSs - presumably various *nix flavours bear enough similarity for sudo to operate in the same way in each, and for it to be compiled from the same source (potentially with OS dependent libraries)?

                It does highlight the chain-of-trust that is assumed with tools such as this, and the potential need for some forensic analysis of flaws in such...

    2. Jou (Mxyzptlk) Silver badge

      Re: buffer overflow found in sudo

      Oh please, those nice sarcastic headlines are what I LOVE about thereg...

  3. Anonymous Coward
    Anonymous Coward

    Why does it need both buffer pos and remaining length variables?

    Surely it only needs 1 or the other? Pos = buffsize - remaining or remaining = buffsize - pos

    You never maintain 2 variables that can consistently and easily be derived from eadh other unless speed is

    absolutely critical because you get exactly these sort of issues,

    1. Blazde Silver badge

      Re: Why does it need both buffer pos and remaining length variables?

      With one more variable they could have taken a poll on how much buffer space was left and the bug might've been out-voted.

  4. karlkarl Silver badge

    I'm fine... OpenBSD uses doas instead.

    I guess that is lucky because I am too busy fixing my darn opensmtpd to update sudo as well!

    Software is great ;)

  5. PaulVD

    It's okay - Lennart Poettering is on to it

    A sudo replacement is the next feature to be added to systemd.

    1. Doctor Syntax Silver badge

      Re: It's okay - Lennart Poettering is on to it

      Just don't make jokes like that.

    2. Psmo

      Re: It's okay - Lennart Poettering is on to it

      Upvoted, but I hope your icon is accurate.

    3. katrinab Silver badge

      Re: It's okay - Lennart Poettering is on to it

      You used the wrong icon for your post. Try this one.

      It may not be "the next" thing. But we can be pretty sure it is on the way, and it won't be good news.

  6. Anonymous Coward
    Anonymous Coward

    Cannae wait for systemd-elevate-privileges...

    1. Anonymous Coward
      Anonymous Coward

      @AC - Don't give him the idea

      This wasn't on Poettering list but now if you mentioned it....

    2. Anonymous Coward
      Anonymous Coward

      I sure as hell can wait.

      I'd happily wait until after I retire. And then some.

      1. katrinab Silver badge
        Thumb Up

        It is good.

        It is a systemd free zone.

  7. Irongut

    WSL Ubuntu

    My WSL Ubuntu 18.04.3 LTS install has sudo v1.8.21p2 installed but pwfeedback is not enabled.

    So a vulnerable version but with a safe config.

  8. Neil Barnes Silver badge

    My mint 19.3 has it enabled; previous versions haven't had it.

    Sadly, the instructions I found didn't provide an obvious way to remove it; it's not defined in /etc/sudoers but one of the included files, and I haven't investigated them yet.

    1. Blasio Muscat

      You want to look at /etc/sudoers.d/0pwfeedback. Change its contents to:

      Default !pwfeedback

      or just remove the file until sudo gets patched.

    2. swampdog

      In here it seems..


    3. Anonymous Coward
      Anonymous Coward


      I'm probably a bit older on that version. Though I have done updates at times. Will check the folders.

      Irritating such a simple feature gets a buffer overload. Could they not just match keypresses to * without passing the actual characters (to the faulty pwfeedback)? Faulty by design IMO, as my bro in the field says "if the data is never there, you can never accidentally leak it!"

    4. Neil Barnes Silver badge

      Thanks all. That's the animal.

  9. Claptrap314 Silver badge


    I remember the concerns about Sudo when I was in grad school, 92-4.

    After init and your shell, if there is one service that you must get right to ensure system integrity, sudo is it. Looking at the bugs in sudo that have come out in the last five years, I cannot help but think that this service was never architected with security in mind. Certainly, the steady drip of whoopsies says that it is not being maintained as if it were a critical security service.

    Currently, sudo.c and sudo.h appear to be a bit over 57k. Of course, if you take the entire source directory, you get more like 300k, including several files that are specific to OS or tty.

    I would argue for a complete clean room implementation, but historically, the expected behavior has been as ripe for failures as the implementation. Anyone up for safesudo?

    Beer, 'cause I'm crying in it.

    1. Doctor Syntax Silver badge

      Re: SUDepressing

      " Anyone up for safesudo?"

      Or sudont?

    2. AJ MacLeod

      Re: SUDepressing

      It kind-of already exists - OpenBSD's doas has a Linux port. I've been using it on a few systems and quite like it... it's not feature-compatible with sudo but it handles pretty much everything I've ever used sudo for.

    3. Loyal Commenter Silver badge

      Re: SUDepressing

      I would ask the follow-up-question, "why has sudo been changing in the last five years"? Sounds like feeping creaturism to me. Such things are never good for software stability, and something security critical like sudo should do the job it is supposed to do, with the minimum of code and fuss, and stop there.

      1. Claptrap314 Silver badge

        Re: SUDepressing

        There may be some of that, but what I'm talking about are the, "Whoops, there's a horrible bug we need to fix"-type changes. Like importing the #$*(@ environment.

    4. nijam Silver badge

      Re: SUDepressing

      ... Anyone up for safesudo? ...

      As I recall, sudo was supposed to be a "safe su". I don't use BSD myself, but doas appears to have exactly the same functionality as sudo.

      1. Claptrap314 Silver badge

        Re: SUDepressing

        "Supposed to be"

  10. jason_derp

    I'm kind of upset

    I'm a little upset that I'm only now finding out that this option even existed. Five years ago I had to google high and low to find out why the hell I couldn't type my password into the terminal (first time Linux user then), and when I finally asked on a forum I was told "Get used to it pleb. Type it correctly and it's not a problem!" or something to that effect. So I did. But I didn't need to when I was learning the ins and outs. #$@!

    This feels like if your dad kept tossing you down a hill on your bicycle until you got it, then half a decade later you see a kid on training wheels.

    1. Dave559 Silver badge

      Re: I'm kind of upset

      Actually, your dad would be right: kids learn how to balance and ride more easily if they get experience scooting along first, with the saddle lowered and pedals removed, than they do with the false "assistance" of stabilisers/training wheels.

      1. John Robson Silver badge

        Re: I'm kind of upset

        Training wheels actually encourage the wrong behaviour, because you lean out of corners....

        They are usually considered to be counter productive when learning to ride a bike.

        And it is the same reason that most people can't ride a tricycle, they tend to throw you out of the path at the first corner, whether there is a wall or a hedge there is of no concern.

    2. Anonymous Coward
      Anonymous Coward

      Re: I'm kind of upset

      Except unless you randomize the number of *’s printed, other people can see how long your password is exactly. If you DO randomize then, it can really confuse people, especially when they typo and hit backspace.

      1. phuzz Silver badge

        Re: I'm kind of upset

        But if they're leaning over your shoulder they can hear how many keys you hit, so they know how long your password is anyway, plus they can probably see which keys you pressed.

        On the other hand, for people who aren't as comfortable using computers, not being able to see if they've typed a character or not can be very confusing, which leads to more wrong passwords, which leads to more support calls.

        Cue me on the phone having to persuade someone to try typing in a password again even though they're convinced they've already typed it in correctly.

        I'm sure the response to this will be "well they should learn to type better", from the exact same people who wonder why Linux isn't more widespread.

        On a similar tack, LUKS disables the capslock light, because apparently if someone can see when you've turned capslock on as you type your password, that's too insecure. Yes, there are many people out there who don't understand the shift key, and will type capital letters by pressing \capslock on/ *letter* \capslock off/, and I deal with some of those people on a daily basis. Even just an option to allow the 'insecure capslock light' would save me a few support calls, but no.

        1. Anonymous Coward
          Anonymous Coward

          Re: I'm kind of upset

          I'm sorry to be the one to say this to you, but... If you're in IT (seeing as this is a IT site) and you still type slow enough where somebody can easily count the keystrokes, then maybe it's time for you to find a new vocation :(.

          I might not type properly or even as accurate as a professional typist, but after years of IT I can at least type fast enough where clicks aren't totally easy to count.

          Although I totally agree about the Caps Lock thing, that's just totally stupid. I normally at least check the LED status to make sure it's NOT on before I type my password!

  11. 1752


    So what, anyone any use UAC to get administrator rights? What?

    Oh wait, this is only nix!!! (with certain config).

  12. Paul Hovnanian Silver badge


    ... was implemented (poorly) to shut up a bunch of users who couldn't deal with password entries not echoing anything. This was the behavior of terminal based utilities since the first days of Unix. Part of the reasoning was that echoing anything back (like an asterisk) could allow a shoulder surfer to count the number of characters in one's password, making attacks easier. So patch requests were addressed with a WONTFIX. But the whining continued. And this is what we got.

    If you cry long and hard enough, you can even get systemd.

    1. sabroni Silver badge

      Re: pwfeedback

      What are you saying? That it would be impossible to implement this without a buffer overflow?

    2. phuzz Silver badge

      Re: pwfeedback

      Gods forbid that an OS should be usable by normal people. After all, the biggest threat from someone stood close enough to count the number of asterisks on your screen is that they could count the characters in your password, rather than just watching which keys you press, right?

  13. Anonymous Coward
    Anonymous Coward

    Mint 18.3

    Mine has the dodgy 'sudo' version, but "pwfeedback" isn't enabled by default. So that's alright then, I presume.

  14. Oh Matron!

    I wonder what Phil Collins thinks...

    I mean, he did sing about Su Su Sud(i)o right?

    I'll get me coat

    1. Just Enough

      Re: I wonder what Phil Collins thinks...

      Well, he's had 35 years to think about it, after this joke was first cracked. He must have a killer of a response by now.

  15. Anonymous Coward Silver badge

    So am I right in thinking that "sudo make me a sandwich" will not allow me to have beetroot as well?

    1. John_S

      I don't know about sudo, but Cole's law means you can't do that!

    2. Loyal Commenter Silver badge


      You're a sandwich

      And your second wish?

  16. MrZoolook


    ... Linux just works.

  17. jonnycando

    I gotten a plethora of updates here lately.....Linux boxes, MacOS boxes......I guess they were ALL updates to Sudo.

  18. grs1961

    Oh good, the "sudo" on my Solaris boxes is old enough not to have this stupidity, and they are the only ones that have public interfaces. (Who says security by obscurity never works?!?!? ;-) )

  19. Jamie Jones Silver badge

    What is somewhat

    sudo It's somewhat amusing to

    sudo see people who

    sudo bang on about the

    sudo insecurities of "su"

    sudo but the procede to run

    sudo just above every command

    sudo preceded by sudo.

    1. Jou (Mxyzptlk) Silver badge

      Re: What is somewhat

      I love sudo /bin/bash and then do the work since a lot of things don't sudo well. Mostly it for my lazyness for ssh keyexchange and then keyauth without the need for a password for automated jobs (or Orcale and a few other applications...). Which brings in the other weakness that 0/0 is always root. Everywhere...

      Another thing I prefer about windows in comparison. My main machine has:

      Name : Administrator

      SID : S-1-5-21-620362388-xxxxxxxxxxx-xxxxxxxxxx-500

      My Server 2019 (workgroup, I am at home):

      Name : Administrator

      SID : S-1-5-21-3213853355-xxxxxxxxxx-xxxxxxxxxx-500

      So upon installation (or image cloned with sysprep, as example) those numerous local account (Administrator, guest, default etc etc) get their own sid. On every machine.

      Only the first part and the last is the same, documented at

      I do like Linux and unix, but some things about its design bothered me over decades, and still bothers me.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like