The recent bash functions bug in sudo sets a bad precedent for sudo use, the idea that users should not be able to break out of a sudo session. In reality sudo is designed to only be used by users who can be trusted not to abuse their sudoers entry, as breaking out of a sudo session is going to be trivially easy in almost any situation. Using sudo is akin to setting the suid bit on random applications, applications that will not be designed to run with suid privileges (for example, these applications will not drop privileges or use extra sanity checking to ensure secure operation), so any minor error that would not generally be important (for example, insufficient bounds checking on arguments or unsafe tmp file handling) suddenly becomes a local root. of course, there are bound to be hundreds of these errors, i'm sure a 5 minute run with a fuzz tester will uncover more than enough on any application that was never intended to run suid. Declaring this a security bug was not a great idea, announcing it "fixed" basically states it's safe again to let untrusted users get sudo access to shell scripts, of course this is not the case. IFS, PATH, CDPATH, PERLIO_DEBUG, etc, etc can all still be (ab)used to elevate privileges. (I asked the maintainer for his opinion on the matter, and he agreed it wasnt a big deal). sudo was simply not designed for this, if this mode of operation is to be supported the floodgates are going to be opened for security vulnerabilities as the idea of sudo is fundamentally flawed for this.
heres a variable I just thought of that means guaranteed root on any bash script if you can set variables, SHELLOPTS. $ csh % setenv SHELLOPTS xtrace % setenv PS4 '$(any command you like)' % sudo /any/bash/script I don't see how these are any different from the bash functions thing*, or any of the of the other "vulnerabilities" that i'm sure exist in any other program or interpreter. *In fact, this ones worse, you dont need to know any of the commands used in the script!
I agree with you that if sudo is not any safer now than it was before the recent patch, we shouldn't issue a GLSA about it, and we should probably alert vendor-sec about your concerns. However, I'm not sure I understand the issue completely. In my understanding, setting env_reset in sudoers would close all ENV-inheritance sudo issues, right ? So maybe we should just issue a GLSA telling people to either : use env_reset/env_keep, or do not allow sudo to call shell scripts. In all cases we should not rush out, and be sure to make your point heard by other distributions...
Yep, except PATH, but I'm planning on adding SECURE_PATH option in the ebuild. Even so, some variables are transferred to the new environment unaltered and are bound to trigger some overflow in some application (I remember seeing several $TERM based bugs). But I was only using environment variables as an example, as they're easy to demonstrate and follow the bash functions bug template, telling people clearing the environment makes it safe to run any application suid root is just as bad :) The only reason sudo is safe to use is because only trusted users are allowed to access it, if you add an untrusted username to the sudoers file, that person will eventually get a root shell. it's that simple, and there's no way around it. Applications that have never been audited or designed to run suid root are bound to have some feature/error/bug/routine somewhere that makes it possible to elevate privileges, perhaps they search for a configuration file that the user can inject commands into, perhaps they will dump an error log to an unsafe location in some circumstances, perhaps they have insufficient bounds checking on an argument, these things wouldnt normally be important and if it was my package, i probably wouldnt bother fixing them if someone reported it...after all, who is going to try and exploit a vulnerability to execute commands as themselves? but under sudo, it's a local root.
solar & others: your opinion on this ? Should we : 1- consider that the bash functions and env issues were real issues, that sudo is fixed now and so we should issue a GLSA, just adding a note that people should restrict the use of sudo to trusted users and trusted applications 2- consider that it's not a vulnerability (it's by design) and that the 'fix' doesn't fix anything, so no GLSA and shut up. 3- consider that it's not a vulnerability (it's by design), that all the hype must be stopped, so no GLSA and tell to vendor-sec how silly they are 4- consider that it's a vulnerability, that it's only partially fixed and that we should forward our concerns to vendor-sec My opinion is somewhere between (1) and (2)...
A sec announcement was released by the sudo people. I disagree with the author with the fix and think the only right one is to env_reset which he says will be added to sudo at a later time. With the env_reset most of the concerns on this bug become moot. If with env_reset and your still able to gain a uid 0 shell then it's clearly a vuln that should be fixed. I agree that sudo should never be used with a shell script in the first place.. But we did not arrive at this bug if that were the case in pratice. #1 I consider that the env is the real issue. #2 (the 'fix' doesn't fix anything) #3 (I don't know why vendor-sec is silly) #4 Yes. when we have attached examples here of other ways this can be exploited.
I said from the start that I don't see this as a sudo vuln, it's ``expected behavior'' (feature, not a bug). While Tavis is right that allowing sudo access to run anything is akin to giving root out, well, duh; allowing sudo access to run anything *is* akin to giving root by design. It allows you to run applications as root. What sudo does allow you to do securely (as far as I can tell--assuming env_reset, etc function correctly) is run *specific* commands as root, akin to setting those commands suid (but allowing greater flexibility both in who can run them as suid and what they can run them on). This is only insecure if you allow your user to run insecure programs, just as with suid; if you set shell scripts suid, you're asking for it. This is not a bug. It's by design. This does not mean I advocate rampant use of sudo; I don't have it installed and have never used it to allow this sort of limited access to untrusted users (what access would one want to give to an untrusted user, anyway?). But sudo does, as far as I can tell, exactly what it claims to do. To call this a vulnerability is like calling telnet vulnerable because it allows remote unencrypted access (which, while certainly a poor idea in many networks, is *by design* and only an issue if you use telnet where you should not). Point being, in my mind, vulnerabilities are unexpected, unadvertised behavior that allows one to attack a system. Expected, advertised behavior that allows such is not a vulnerability.
Also, why is this resticted viewing? Bug 70838 is not restricted. And I believe unless there is good reason (is there here?), we should try to maintain transparency in our security process. Tavis, can we open this bug?
I asked Tavis to file this as restricted until we sorted out what to do (alert v-s/update docs).
> #1 I consider that the env is the real issue. But surely you agree that clearing the environment is not enough to make running any application you have installed suid root? > #2 (the 'fix' doesn't fix anything) agreed :) > #3 (I don't know why vendor-sec is silly) As I understand it, some vendor-sec people put pressure on the sudo maintainer to publish an advisory against his better judgement. > #4 Yes. when we have attached examples here of other ways this can be exploited. Hmm! When I read this I thought for a while of a simple way to exploit this that would demonstrate my argument. I think I have thought of one that will satisfy you: Read any file on the filesystem (eg, /etc/shadow) if you have sudo access to a program that uses terminfo, or a shell script that uses a terminfo compatible program (eg, reset, tset, tput, common terminal utilities). Or under some circumstances, execute any program. Exploit: browsing terminfo documentation, I spotted these: reset_file rf rf name of reset file init_file if if name of initialization file These files are sent to the terminal to initialize or reset them. init_prog iprog iP path name of program for initialization This one looked promising, but I can only get it to work with the tack program...which I guess nobody is going to be handing out sudo access to. anyway, perhaps some other applications support it that i dont know about. So, I made my own simple terminfo file: $ cat > owned.src owned,rf=/etc/shadow, ^D $ tic owned.src $ cat /tmp/script #!/bin/bash reset $ TERM=owned sudo /tmp/script <contents of /etc/shadow displayed here> Remember, the TERM isn't important, because sudo lets you pass the TERM variable even with env_reset, and even if it didn't, you could just make a terminfo file for whatever your term really was.
I would agree that giving an untrusted user root access to an untrusted application is not a vulnerability. I think we just need to educate the user by commenting the sudoers file, and not issue a GLSA about this. See bug 70838 for the public discussion.
Oh, I don't mind making this bug public if nobody else objects. (Sorry Dan, missed your question).
No need for keeping this restricted anymore. I agree that we should update sudoers and perhaps Gentoo Security Guide. If needed I can submit a small fix for that.
Switching to "default configs" component. /etc/sudoers needs more warnings.
instead of sending a glsa, how about sending a statement, like: "Gentoo's position on the recent sudo advisory is that no vulnerability has been fixed, giving an untrusted user a sudoers entry is no safer than prior to this update. To ensure consistent behaviour with other vendors, gentoo has applied the patch provided by the sudo maintainer, but will not be publishing a glsa on this matter. As usual, users should exercise caution when allowing sudo access on their machines, and should never permit untrusted users to execute applications with elevated privileges. see bug #71750 for discussion." Feel free to ignore/modify/correct as you see fit :)
Tavis please update /etc/sudoers as per comment #13.
How's this (assume it's in a monospace font that aligns nicely :) : # *** REMEMBER *************************************************** # * GIVING SUDO ACCESS TO USERS ALLOWS THEM TO RUN THE SPECIFIED * # * COMMANDS WITH ELEVATED PRIVILEGES. * # * * # * ONLY PERMIT SUDO ACCESS SPARINGLY. * # * * # * NEVER ALLOW ACCESS TO UNTRUSTED USERS. * # * * # * IF YOU DON'T KNOW A COMMAND IS SAFE TO USE WITH SUDO, ASSUME * # * IT ISNT, AND PERMIT ACCESS ACCORDINGLY. * # **************************************************************** I could write a few paragraphs on the subject, but i suspect people wouldn't read it :) any feedback?
This is enough all caps for me:-)
Tavis please commit.
done
Thx Tavis.
