Privilege escalation vulnerability.
Closed this issue · 5 comments
The initial implementation does not run user scripts as the target user; nor checks to see if the script being run is owned by the user; only if it's readable and executable by the "owner". Then all scripts are run as root, even the local ones. This could allow and attacker to use a non-privileged account to execute root level commands if the PAM Duress module is employed.
Repro steps:
Resolution as a quick fix will be to run all commands spawned from the pam_duress.o module via su - [USER] -c [COMMAND]. This will also cover ownership permissions issues because if user X tries to run a duress script they aren't the owner of or don't have group permissions for, it will fail, so explicit checking should be a requirement moving forward but in the interest of closing the security hole, changing the command used to execute scripts is the fastest way to patch sufficiently to stop privilege escalation.
So, first off, thanks for this tool - it's great.
The privilege escalation issue here is certainly one that is an issue, but
unless I'm mistaken, this fix dramatically reduces the functionality of the
tool.
Many "cleanup" procedures that might need to be run if a duress password is run
require root privilege. Unmounting and cryptclosing encrypted drives is the
example I'm currently playing with but I'm sure there are many others. Am I
right in thinking that these sorts of operations would no longer be possible
with this fix applied?
No, root privileges are still possible with scripts run from /etc/duress.d. There's even a fix in the current PR because how the privilege escalation issue was initially fixed actually broke running scripts from /etc/duress.d.
The logic is you don't want a user account to have ownerships of scripts that are run with root privileges; that's generally bad practice and scripts run by root or other functional users should only be edited with sudo.
Now user scripts could still be coded to run commands as root if they have sudo permissions, but best practices for sudo permissions should also limit that. In any case even if someone has unrestricted sudo access they should still maintain root as the owner of those scripts. That way even if an attacked gets access to the shell by means other than a password (leaked ssh key, vulnerable web app run under the user, etc), then the attacker can't use the scripts run under /etc/duress.d to escalate their privileges.
That makes sense, thanks for the quick reply and explanation.
Feel free to review the open PR if you have a chance! I'm humbled by the attention the project is getting and would love 3rd party review of the code. The current main brach actually still had the bug that breaks /etc/duress.d functionality.