Serious Flaw That Lurked In Sudo For 9 Years Hands Over Root Privileges (arstechnica.com) 96
An anonymous reader quotes a report from Ars Technica: Sudo, a utility found in dozens of Unix-like operating systems, has received a patch for a potentially serious bug that allows unprivileged users to easily obtain unfettered root privileges on vulnerable systems. The vulnerability, tracked as CVE-2019-18634, is the result of a stack-based buffer-overflow bug found in versions 1.7.1 through 1.8.25p1. It can be triggered only when either an administrator or a downstream OS, such as Linux Mint and Elementary OS, has enabled an option known as pwfeedback. With pwfeedback turned on, the vulnerability can be exploited even by users who aren't listed in sudoers, a file that contains rules that users must follow when using the sudo command.
"Exploiting the bug does not require sudo permissions, merely that pwfeedback be enabled," an advisory published by sudo developers said. "The bug can be reproduced by passing a large input to sudo via a pipe when it prompts for a password." The advisory lists two flaws that lead to the vulnerability. The first: pwfeedback isn't ignored as it should be when reading from something other than a terminal. As a result, the saved version of a line erase character remains at its initialized value of 0. The second contributor is that the code that erases the line of asterisks doesn't properly reset the buffer position if there is an error writing data. Instead, the code resets only the remaining buffer length. As a result, input can write past the end of the buffers. Systems with unidirectional pipe allow an attempt to write to the read end of the pipe to result in a write error. Because the remaining buffer length isn't reset correctly when write errors result from line erasures, the stack buffer can be overflowed. The report notes the vulnerability was introduced in 2009 and remained active until 2018, with the release of 1.8.26b1. "Systems or software using a vulnerable version should move to version 1.8.31 as soon as practical," reports Ars. "Those who can't update right away can prevent exploits by making sure pwfeedback is disabled."
"Exploiting the bug does not require sudo permissions, merely that pwfeedback be enabled," an advisory published by sudo developers said. "The bug can be reproduced by passing a large input to sudo via a pipe when it prompts for a password." The advisory lists two flaws that lead to the vulnerability. The first: pwfeedback isn't ignored as it should be when reading from something other than a terminal. As a result, the saved version of a line erase character remains at its initialized value of 0. The second contributor is that the code that erases the line of asterisks doesn't properly reset the buffer position if there is an error writing data. Instead, the code resets only the remaining buffer length. As a result, input can write past the end of the buffers. Systems with unidirectional pipe allow an attempt to write to the read end of the pipe to result in a write error. Because the remaining buffer length isn't reset correctly when write errors result from line erasures, the stack buffer can be overflowed. The report notes the vulnerability was introduced in 2009 and remained active until 2018, with the release of 1.8.26b1. "Systems or software using a vulnerable version should move to version 1.8.31 as soon as practical," reports Ars. "Those who can't update right away can prevent exploits by making sure pwfeedback is disabled."
Re: (Score:1)
Exploit does not work on Mac OSX (Score:2)
Mac sudo does not have the passwordfeedback flag on
Re:Exploit does not work on Mac OSX (Score:4, Informative)
https://appleinsider.com/articles/20/02/03/fixed-sudo-flaw-in-macos-gave-root-command-privileges-to-all-users [appleinsider.com]
Re: Exploit does not work on Mac OSX (Score:3)
Actually, it was Apple that found the bug.
But Slashdot would never report something like that. Doesnâ(TM)t fit the narrative.
https://www.sudo.ws/alerts/pwf... [www.sudo.ws]
Re: (Score:3)
Newer language like Rust help create safer practices, but it doesn't make them safe.
But amateur developers who run into these safety procedures are often the first to bypass them. Mainly because their lack of experience means when you hit a security feature stoping doing what you want, they don't have the training to go back and approach the problem differently, but find ways to disable the protection so it can get going to the next step.
Re: (Score:2)
And that is why the whole approach is flawed: Those that need these safety-nets need them because they do not know what they are doing. And hence the net is ineffective, because it addresses the wrong problem.
Re: (Score:2)
Safe languages are not a bad idea. However the rush to rewrite your code in this new language isn't going to solve problems.
Re: (Score:2)
I agree that "safe" languages have their place. But they are not a good fit for every problem and they do only fix one specific class of problems and have their own security issues (like people working around protection mechanisms) and other problems.
In the end, they are just one more tool. What offends me in the typical narrative pushed by the Rust fanatics is that they claim Rust would fundamentally make things better and basically have no drawbacks. And that is just a plain, direct lie.
Re: (Score:1)
Re:Automated source tools (Score:5, Insightful)
Just curious, how on earth do you do "root" stuff then? Sometimes you just have to be root so how do you do that without sudo? Is that secure?
So I'm not going to give you too much flack, I'm just going to say it's unlikely that your means of privilege escalation is as safe as sudo, even with this bug. I suppose it's possible to do all sorts of complex stuff with setuid bits and captive utilities, but sudo is going to be way more secure and more easily logged to trace back to who did what (if you care about such things).
Re: (Score:1)
Just curious, how on earth do you do "root" stuff then? Sometimes you just have to be root so how do you do that without sudo? Is that secure?
So I'm not going to give you too much flack, I'm just going to say it's unlikely that your means of privilege escalation is as safe as sudo, even with this bug. I suppose it's possible to do all sorts of complex stuff with setuid bits and captive utilities, but sudo is going to be way more secure and more easily logged to trace back to who did what (if you care about such things).
RTFM hint: $ su -
Re:Automated source tools (Score:4, Insightful)
"su" is LESS SAFE than "sudo." So bobbied's point stands.
sudo offers superior logging, finer-grained control, and since you have to type it each time you are less likely to seriously screw something up if you mistype your NEXT command (which doesn't require su but would still have it if using su).
Re: (Score:2, Informative)
So while a bummer to see this exploit, that should not discourage anyone from using it and it is a de-facto tool in the sysadmin toolkit.
Ditto what Brian-Fu said in that I'm curious how the "su - works just fine" people log their commands, provide some granular control (by use
Re:Automated source tools (Score:4, Interesting)
And let me know how well that scales with you have hundreds/thousands of machines and dozens of Sysadmins ...
Only necessary if your systems don't have the facilities to provide each administrator with the authorization they need to do their jobs.
sudo is a Band-Aid a hack to enable something that shouldn't ever be necessary in the first place.
Re: (Score:2)
Re: (Score:1)
Re: Automated source tools (Score:5, Interesting)
Except using pwfeedback isn't the default and I can't remember ever using a system that had it configured. Obscure corner case as far as I'm concerned.
Re: Automated source tools (Score:1)
Re: (Score:1)
"su" is LESS SAFE than "sudo." So bobbied's point stands.
Personally I have the exact opposite perspective.
Not only is typing sudo before every command a pointless waste of time but the inevitable descent into automating inclusion of sudo prefix in script snippets is a bigger risk than what sudo purports to solve.
If I'm logged on as an end user and some gunk gets into my paste buffer or I type the wrong thing it can't escalate with su. With sudo I'm at constant peril of something going wrong vs peril being limited to explicitly when root is required.
Personally I
Re: (Score:3)
If I'm going to do a bunch of stuff as root I sudo su. But where sudo is really helpful is when I want to automate something. Sudo lets me give passwordless access to a command with specific arguments as root. That way I avoid needing a setuid script.
Re: (Score:3)
If I'm going to do a bunch of stuff as root I sudo su.
sudo su has been redundant for more than a decade. That's now 2 processes instead of 1. You should read the man page on how to use sudo -i
Re: (Score:2)
Oh noes, two processes! How will I ever cope?
Re: (Score:2)
You don't need to cope with two processes. You need to cope with the mockery of using a command that was made redundant years ago. LOL sysadmin fail.
Re: (Score:2)
I'll remember not to let you into the office, mockery problem solved.
Re: (Score:2)
If I'm going to do a bunch of stuff as root I sudo su. But where sudo is really helpful is when I want to automate something. Sudo lets me give passwordless access to a command with specific arguments as root. That way I avoid needing a setuid script.
And what happens when said program needs to do something that depends on and respects the end users actual authorization level?
I get why people do this shit and I'm not saying that people are wrong to take a course of action given set of real world constraints.... but wouldn't it be better to delegate authority rather than pretend to be something you are not?
These schemes are crummy hacks that shouldn't be necessary in the first place.
Re: (Score:2)
Personally I would rather su not exist at all and everyone be forced to declare authorization level they want during login. At least then the true effective authorization level of your shell isn't something you ever have to think about.
You can try single user mode if you think you'd enjoy it more. (I doubt you will)
Re: (Score:2)
I agree. If you can do anything as root, you likely can become root. (Exception: su-binaries that have been locked down very, very carefully.) It is exceptionally difficult to configure sudo to be really secure. Better accept that some people have to be given a root-shell and do that.
Re: (Score:1)
su is hard to audit, it doesn't log all the commands executed as root, that much is true. For many years we used to hack in all sorts of weird things that would log the shell just because we didn't have something like sudo, or refused to use it (for [not likely valid] reasons).
Saying that su is less safe than sudo isn't true, it's has less features and could conceivably have fewer bugs with the same amount of testing effort. In practice, I suspect out of the various Unix environments that some of their su i
Re: (Score:3)
and since you have to type it each time you are less likely to seriously screw something up if you mistype your NEXT command
There are good things about sudo, but this is a really stupid argument that I see repeated over and over again.
First of all, do you actually just randomly type in stuff that would hose your system, because you're not root so it seems OK? It is an absurd argument.
Second, not doing anything as root that isn't sysadmin stuff is a totally separate best practice than using sudo. There is no reason to just presume that a person who does "sudo su -" before a series of system administration commands is also using t
Re: (Score:2)
What if I needed to copy all my cat videos to /root?
Re: (Score:2)
Then you RTFM and discover the -i flag, and all is well.
But if you su to root, the distro most likely included an alias for cp that already adds that flag, so it would be fairly safe. Safer than sudo in this example.
Re: (Score:2)
I know that on at least one occasion when intending to type 'rm -rf .*' accidentally typed a space instead of a dot. Not very clever, but an 'honest' enough mistake when you're distracted...
Re: (Score:2)
Oops. I meant to type [name].*. But I used angle brackets and Slashdot nicely removed them for me. See how mistakes get made... ;-)
Re: (Score:2)
Well, that is a dumb thing to do. If you're using rm with wildcards, slow the fuck down cowboy, double-check, triple-check before you hit enter.
Using sudo or using a root login has the exact same results if you just type that shit and hit enter.
So no, that is an absolutely horrible and specious example.
Do you actually mean that you were doing non-system-administration stuff as root, and so almost deleted extra stuff? That has nothing to do with sudo or su.
Personally, I test my wildcards with ls before throw
Re: (Score:2)
Well, I never did it as root ;-)
Re: (Score:2)
Well, I never did it as root ;-)
So why were you using sudo or su - to do it?
Re: (Score:2)
So you just add -f for "force, I know what I am doing" to random delete commands you don't double check..
You are such a dumbass.. I would know, I do the same ;)
Re: (Score:2)
A lot of people just type
sudo su -
which to my mind needs to be banned since it negates the point of sudo.
Re: (Score:2)
And "sudo su -" SHOULD be banned.. Which, by happenstance, IS totally possible when using sudo.
I know that lazy folks just set up sudo to allow anything without a password, but that is NOT how the utility is supposed to work. It is very possible (and indeed desirable) to lock down the commands that sudo allows to just the subset needed to do one's job.
When you properly setup and use sudo, it is indeed much more secure and auditable. Of course, lazy admins often don't do all the work they should do an
Re: (Score:2)
While it negates some of logging and access control, there are valid use cases for it.
If i need to test multiple commands involving long similarly looking filenames, i use mc, which allows faster filename copying, and generally is much more comfortable than pure shell. Sorry, but i don't want to TAB-complete for 20 pages of filenames, mc provides me that way easier.
Re: (Score:2)
Any data to support this?
Re: (Score:2)
nitpicking I'm sure but... (and reply isnt just for you but the thread in general)
There are times, like when piping or what ever commands you need to be root, sure there is sudo -i or -s which is sudo but does switch you user. /root/tmp"
try "sudo echo hello >
Try even traversing looking in nested directories that your user doesn't have access to with sudo ....
Re: (Score:2)
No, su is safer than sudo. Infinitely so. It is a separate account and separate password, that offers proper separation of priviledges, instead of only providing an illusion of security and the most minimal hurdle to cross for an attack.
Re: (Score:2)
bah
sudo bash
that way I can get all the insecurities of both methods.
Re: (Score:2)
Never give me access to a text editor. I can cause a lot of problems just from that.
I had a job where I didn't have Dev tool for a few months. However using Shell scripts and creative database queries I was able to make an interactive web application.
Re: (Score:2)
sudo bash is redundant and spawns 2 processes. Read the man page. sudo -i has been around for more than a decade.
Nope. (Score:4, Interesting)
Quoting from the manpage:
The -i (simulate initial login) option runs the shell specified by the password database entry of the target user as a login shell.
sudo - i does spawn a shell.
sudo bash litteraly asks for a shell to be spawned.
both spawn the same amount of process.
(the difference is in what is spawned:
- the target user might have specified zsh as a shell, wereas the command line will explicitly resquest bash
- sudo -i always spawns a new login environment (eg.: loading all scripts like profile) whereas one would need to pass the "-l" option explicitly to bash)
Re: (Score:2)
You worried about running out of processes?
Re: (Score:3)
That said sudo bash does something a bit different than sudo -i
For one, doing a sudo bash does NOT clear out the calling users environment, sometimes you actually want this.
Another point is that sudo -i will always run with the login shell for the account, which may be set to /bin/sh which is often not bash, which may or may not be what you want.
So since you've never checked regarding process numbers w
Re: (Score:3)
Just curious, how on earth do you do "root" stuff then? Sometimes you just have to be root so how do you do that without sudo? Is that secure?
So I'm not going to give you too much flack, I'm just going to say it's unlikely that your means of privilege escalation is as safe as sudo, even with this bug. I suppose it's possible to do all sorts of complex stuff with setuid bits and captive utilities, but sudo is going to be way more secure and more easily logged to trace back to who did what (if you care about such things).
RTFM hint: $ su -
That is not safe and will not log what you do as root.
Yea, it does escalate your privileges (assuming you have root's password) but there are a couple of serious problems with this...
1. Root must have a matchable password - Meaning that ANY user with the root password can escalate their privileges, including a hacker who manages to get an interactive login into your system. With sudo, you can specifically control who gets admin privileges without sharing a password.
2. Changing who has access requires cha
Re: (Score:3)
Yes, there are a multitude of code scanners available. They don't pick up on everything. For the rest, we have the thousands of eyes on open source code. Look at it this way, if this was closed source software, then the vulnerability would likely still exist now. You just wouldn't be aware of it.
I use sudo to grant/revoke admin access for specific accounts, to specific machines. This way, I don't have to hand over a root password. The logging is a bonus. Sudo is not an especially complex layer. If y
Re:Automated source tools (Score:4, Funny)
Re: (Score:1)
Re: (Score:3)
Good point. Mind you they probably knew about the sudo bug as well, they're very non-partisan there.
I think the deciding factor is to use an OS where they have more incentive to reveal the holes than hoard them, i.e. where enough of their own side is potentially compromised that they're motivated to get the hole patched rather than hold it for exploitation.
Re:When will people learn to stop using C (Score:5, Insightful)
It's not a matter of people "learning to stop using C" (unless they are developing new software in C, which I suppose still happens, but not often).
It's a matter of people continuing to use the trillions of man-hours of software that has been written in C over the last 5 decades.
People will stop using that software sometime after viable (non-C-based) replacements have been written, debugged, tested, qualified, and adopted by all of the major OS distributions. Until then, demanding that people not use C is as realistic as demanding that people not use their computers at all.
Re:When will people learn to stop using C (Score:5, Insightful)
Why do some people pretend that bugs don't exist in code written in other languages?
Yes, perhaps this bug might not have been there. Other bugs could have been instead. Is all your code 100% bug free? Great, then you can write the next sudo and nobody will ever find any exploit for it, I guess.
Reality suggests otherwise.
Re: (Score:2)
Why do some people pretend whole that whole classes of bugs exist that exist in C exist in other languages?
It's not about whether bugs exist in other languages. It's about that the set of bugs in other languages is usually strict subset of the bugs in C.
Re: (Score:2)
That's why I was so hesitant to try rust.
From my limited experience with it, rust seems at first glance to be a fairly nice usable language that is a little lacking in libraries. I was quite shocked I was expecting a language that was awful to use so as to make it "safe".
Re: (Score:2)
People say this and say this and say this, and yet the actual rates of bugs and security problems remain fairly constant across different languages.
Say it some more, maybe it will get more true if you say it enough times.
Re: (Score:2)
To suggest that smaller attack surfaces aren't effective is to deny basic security principles. C (and its most common idioms) has a larger attack surface than most languages.
Re: (Score:3)
Liar, liar, pants on fire.
Indirection, boilerplate, and restrictions on the programmer all create additional attack surfaces.
Empirical evidence does not support the claim that there is a difference in attack surface.
It is based entirely on mistaken ideology.
I use C often. I also use Go often. Because it has an attack surface I consider preferable in certain use cases. But not in others. Sometimes I use Ruby. It has a better attack surface in some use cases. Sometimes the attack surface depends larges on the
Re: (Score:2)
There are bugs in other languages that are strict subsets of the bugs of the other languages.
For a start, any bug in the interpreter/VM of any other language is a bug that doesn't exist in C.
Re: (Score:1)
All that RAM and CPU power is ready this decade
Re:When will people learn to stop using C (Score:5, Insightful)
C gives superior control over low-level operations, allowing for superior performance. Languages that always enforce redundant safety checks will cost you some performance. For some applications, this is totally acceptable. For others, it is not.
Related quote:
Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn
Re: (Score:2)
The problem here is that there's nothing about the "sudo" utility that demands cleverness. Its single purpose in life is safety and security.
Unfortunately, this is yet another case where developers weren't quite clever enough to wield C's treacherous and demanding low-level string manipulation facilities in an airtight fashion.
Re: (Score:2)
C also requires less boilerplate and indirection, which mask bugs.
Re: (Score:1)
People will probably stop using C when Turing machines are eclipsed by something else. There are many security bugs found in C applications because the majority of infrastructure and cryptography code is written in C. It's sort of like saying that most traffic accidents happen in automobiles, so we need to replace them with something else.
Almost every computing platform in existence for the last 40 years has had a C compiler; this because it provides an efficient, comprehensive, and largely portable means
Re:When will people learn to stop using C (Score:4, Interesting)
Many of the Unix commands were written to work on the early 32 bit systems running only a few megahertz of speed. Networked systems were under 1mbs. These commands were normally typed on a dumb terminal probably at 9600bps.
Buffer overflows at that time were considered more a nuisance than a security risk. However, for most usage exploiting the overflow would just take much too much time.
Now C was meant to be a language one step higher than raw assembly code. There were higher-level languages available such as COBOL and FORTRAN but with C you had nearly direct control of your computer as you did in assembly, without a lot of nitpicking for common requests. The buffer overflow normally caused a segment fault or some funny text, but to have your program perform advanced functions often beyond what other languages have coded to work.
Only by the mid-late 1990s, the buffer overflow became a security problem, as computing speeds are in the hundreds of megahertz, network speed over 1mbs, and 10-100mbs common. Also with most manufactures starting to provide the OS with a standard configuration that means after boot most of the RAM was mapped the same way across different systems, allowing predictable hacks.
By this time there is a large quantity of code that needs to be fixed. Commands such as sudo which are in essence security override tools anyways probably are difficult to analyze for flaws.
Whelp, is it really sudo or pwfeedback not doing (Score:1)
the needful?
The systems I use are all set to allow logins with a valid big key.
Current version on my laptop is 1.8.21p2
Pretty sure there will be an eventual update...
I didn't understand a word of it ... (Score:5, Funny)
... I guess it's sudo science.
Re: (Score:2)
Slackware default setting, no issue (Score:5, Interesting)
Still a bad bug, but something to be said about Slackware's method of keeping the defaults from upstream. Slackware was not vulnerable by default, see: ftp.osuosl.org [osuosl.org]
pwfeedback is a default setting in some Linux distributions; however, it is not the default for upstream or in Slackware, and would exist only if enabled by an administrator.
Re: (Score:2)
I checked my Xubuntu 18.04.3 install and it seems not to be default either (or I'm suffering from amnesia and I fixed this last year or something...heh) :)
Re: (Score:3)
pwfeedback is off by default in any stock sudo/sudoers installation.
It's good that they fixed this bug, but I've never seen this flag enabled in practice.
Re:Slackware default setting, no issue (Score:4, Insightful)
This is something that bugs me constantly in many of these alarm-bell articles. They talk about a security flaw as if the world is ending, and the comments fill up with people lamenting how horrible security has become. But they could have pointed out right at the top that this is off by default in everything, and therefore not really an issue except for corner cases where someone has manually turned it on. This is far from the only instance of this, and it only comes out deep in the comment section that there's really no need to worry.
But I guess that's less sensational, so gets fewer clicks.
Re: (Score:2)
pwfeedback shouldn't have root privileges (Score:2)
Uh-huh (Score:3)
"make sure pwfeedback is disabled." (Score:2)
Okay. And I do that how, exactly?
Re: (Score:2)