Bug 1676925

Summary: script injection pathway through sudo
Product: [Fedora] Fedora Reporter: Thomas Walker Lynch <thomas.walker.lynch>
Component: sudoAssignee: Marek Tamaskovic <mtamasko>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dapospis, fweimer, kzak, mattdm, mtamasko, rsroka, tosykora
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: https://koji.fedoraproject.org/koji/taskinfo?taskID=33864189
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-13 12:56:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Thomas Walker Lynch 2019-02-13 15:54:44 UTC
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

Comment 1 Marek Tamaskovic 2019-03-21 10:28:03 UTC
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.

Comment 2 Thomas Walker Lynch 2019-03-21 16:08:47 UTC
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 ..

Comment 3 Dalibor Pospíšil 2019-03-28 08:23:35 UTC
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?

Comment 5 Marek Tamaskovic 2019-04-01 09:13:09 UTC
Proposal for Fedora rawhide.
https://src.fedoraproject.org/rpms/sudo/pull-request/9

Comment 6 Marek Tamaskovic 2019-08-13 12:56:50 UTC
Closed as it is in rawhide already.