You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Apparently, pam-ussh itself and its recently added euid switching were designed with primarily, or even exclusively, sudo in mind. With sudo, the user controlling the SSH_AUTH_SOCK env var and the user being authenticated are the same, so it's reasonable to switch to that user's euid for accessing the socket (of the user's choice).
Now imagine having the module stacked for su instead. The target user may be e.g. root (this is different from sudo's case), but the env var is under the invoking user's control (just like with sudo). Thus, the invoking user may make pam-ussh access a pathname that is not normally accessible by the user directly. The "pam-ussh: check cert against the pam username" commit hopefully defeats the obvious attack on authentication (although this depends on external/setup detail), but it doesn't deal with the issue of pathname probing (with pam-ussh becoming an oracle, potentially providing 1-bit responses via side-channels), nor with potential side-effects of being able to connect to (even though not talk over) arbitrary Unix domain sockets (not necessarily those of any ssh-agent, bypassing Unix permissions on parent directories and the sockets themselves).
Maybe the README should be re-worded some further, stating that the module is only meant for use with sudo, and any other use may be unsafe? I don't find use e.g. along with su reasonable anyway.
The text was updated successfully, but these errors were encountered:
Apparently, pam-ussh itself and its recently added euid switching were designed with primarily, or even exclusively, sudo in mind. With sudo, the user controlling the SSH_AUTH_SOCK env var and the user being authenticated are the same, so it's reasonable to switch to that user's euid for accessing the socket (of the user's choice).
Now imagine having the module stacked for su instead. The target user may be e.g. root (this is different from sudo's case), but the env var is under the invoking user's control (just like with sudo). Thus, the invoking user may make pam-ussh access a pathname that is not normally accessible by the user directly. The "pam-ussh: check cert against the pam username" commit hopefully defeats the obvious attack on authentication (although this depends on external/setup detail), but it doesn't deal with the issue of pathname probing (with pam-ussh becoming an oracle, potentially providing 1-bit responses via side-channels), nor with potential side-effects of being able to connect to (even though not talk over) arbitrary Unix domain sockets (not necessarily those of any ssh-agent, bypassing Unix permissions on parent directories and the sockets themselves).
Maybe the README should be re-worded some further, stating that the module is only meant for use with sudo, and any other use may be unsafe? I don't find use e.g. along with su reasonable anyway.
The text was updated successfully, but these errors were encountered: