Description of problem: sudo does not reset the prompt. For example bash PS1 and PS2 are passed through. Bash prompts permit executable to be embedded in them. Hence if the sudo target uses the prompt environment values, the embedded script is run as a side effect. (I reported this via email on a day the server was down. I was given, Ticket URL: PNT0475866. So perhaps it now exists on some internal site, but I can't find it, nor track it so I'm adding it here.) Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. remove prompt setting from root .bashrc, if there is one., say comment out the PS1= line. 2. run 'run_this.sh' 3. notice that now the prompt says 'target_running'. Actual results: > ./run_this.sh \n$(/home/user/src/sudo_script_leak/target.sh)\n§\h§\w\n> target running §host§/home/user/src/sudo_script_leak Expected results: as above, but no 'target running' Additional info: https://github.com/Reasoning-Technology/subu/tree/master/try/sudo_script_leak
This bug is not relevant because everything behaves as intended and described in documentation. In addition many times you want to have scripts in the PS1 variable, e.g., pwd. The reason why this works is that the PS1 is inherited to sudo by configuration in sudoers => PS1 variable in env_keep. This means that sudo takes the PS1 variable from user and put it into new environment. If you do not want this behavior to happen just remove the PS1 from env_keep. Another concern that I have is that you used sudo su. This combination many times do not work as intended. Try to use only one of those, e.g., sudo -i.
Documentation is not formally verified to describe a secure system. Hence, this is not a point we can reason forward from and determine if a system is secure. Many people have been harmed by code that functioned as documented. However, I think what you mean to say is that the problem isn't with sudo, but instead is with the configuration of sudo. Yes, that is the mechanism, because PS1, and PS2 are inherited to sudo, and because the shell will execute code referenced in them, it is possible to inject code. And as you note, the example would be better formed using sudo -i to run the shell, and would produce the same results. Seems the default would be to take the safe route and not inherit PS1 and PS2, and thus not have the script injection path. The person adding them back in would be doing so with knowledge of this issue. Alternately, they could be checked. If they don't refer to code, or only refer to code that is trusted, then they are safe. It is hard to imagine a user spending all his time trying to break a system by leveraging something like this, but on the other hand there are a lot of bored comp sci students using linux servers ..
I agree that having the default "safe enough" is a reasonable requirement. It's definitely better than: hey, here you have a vulnerable system, now guess what all you need to do to make it safe. Sounds like an exam or a quiz, doesn't it?
Proposal for Fedora rawhide. https://src.fedoraproject.org/rpms/sudo/pull-request/9
Closed as it is in rawhide already.