search

nuvious / pam-duress

A Pluggable Authentication Module (PAM) which allows the establishment of alternate passwords that can be used to perform actions to clear sensitive data, notify IT/Security staff, close off sensitive network connections, etc if a user is coerced into giving a threat actor a password.
GNU Lesser General Public License v3.0
1.33k stars 39 forks source link

Privilege escalation vulnerability. #1

Closed nuvious closed 3 years ago

nuvious commented 3 years ago

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: image

nuvious commented 3 years ago

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.

Jab2870 commented 3 years ago

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?

nuvious commented 3 years ago

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.

Jab2870 commented 3 years ago

That makes sense, thanks for the quick reply and explanation.

nuvious commented 3 years ago

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.