Summary
#10452 is a security risk because it allows an attacker to replace binaries from PATH with his own version if called from the virtual environment,
Details
I wanted to answer #10452 when i realized that the discussion is heading into the wrong direction and that this bug has a much bigger impact. salt-call is just an example that showcases the problem.
In older versions when i activated the virtual environment the bin folder from the venv-salt-minion was in PATH before any system folder. So for the example of salt-call the version from the venv-salt-minion was used instead of salt-call from a regular salt-minion installation.
Now the virtual environment includes a directory in the first position that looks like garbage but can create a security issue: this directory is not owned or controlled by the venv-salt-minion but can be controlled by someone else.
When someone creates that directory he can override any binary that the virtual env would call using PATH.
PoC
- Create executable /home/abuild/rpmbuild/BUILD/salt-3006.0-suse/venv-salt-minion/bin/which
#!/bin/bash
logger "owned"
/usr/bin/which $@
- Activate the virtual environment:
source /usr/lib/venv-salt-minion/bin/activate
- call
which ls
- look for string "owned" in /var/log/messages
Impact
A user named abuild or anyone who can create the something in /home/abuild can run commands as the user that uses the virtual env activation script.
mayrstefan Reporter
Summary
#10452 is a security risk because it allows an attacker to replace binaries from PATH with his own version if called from the virtual environment,
Details
I wanted to answer #10452 when i realized that the discussion is heading into the wrong direction and that this bug has a much bigger impact. salt-call is just an example that showcases the problem.
In older versions when i activated the virtual environment the bin folder from the venv-salt-minion was in PATH before any system folder. So for the example of salt-call the version from the venv-salt-minion was used instead of salt-call from a regular salt-minion installation.
Now the virtual environment includes a directory in the first position that looks like garbage but can create a security issue: this directory is not owned or controlled by the venv-salt-minion but can be controlled by someone else.
When someone creates that directory he can override any binary that the virtual env would call using PATH.
PoC
source /usr/lib/venv-salt-minion/bin/activatewhich lsImpact
A user named abuild or anyone who can create the something in /home/abuild can run commands as the user that uses the virtual env activation script.