Red Hat Bugzilla – Bug 1494268
pam_ssh_agent_auth SEGV's if keyfile is missing
Last modified: 2018-04-10 14:20:29 EDT
Created attachment 1329217 [details] patch from customer to handle lack of a keyfile Description of problem: Any attempt to use `pam_ssh_agent_auth` without a keyfile present causes a SEGV. Version-Release number of selected component (if applicable): Customer is running their patched version of openssh now: openssh-7.4p1-12.el7_4.0.deshaw.x86_64 Fri Sep 15 12:54:52 2017 openssh-clients-7.4p1-12.el7_4.0.deshaw.x86_64 Fri Sep 15 12:54:52 2017 openssh-server-7.4p1-12.el7_4.0.deshaw.x86_64 Fri Sep 15 12:54:52 2017 How reproducible: Consistent Steps to Reproduce: 1. Any attempt to use pam_ssh_agent_auth without a keyfile present causes a SEGV. Actual results: Segfault Expected results: Better error-handling Additional info: The customer has provided a patch as userauth_pubkey_from_id.c.patch: diff --git a/pam_ssh_agent_auth-0.10.3/userauth_pubkey_from_id.c b/pam_ssh_agent_auth-0.10.3/userauth_pubkey_from_id.c index ee6437b..5386e02 100644 --- a/pam_ssh_agent_auth-0.10.3/userauth_pubkey_from_id.c +++ b/pam_ssh_agent_auth-0.10.3/userauth_pubkey_from_id.c @@ -66,6 +66,9 @@ userauth_pubkey_from_id(const char *ruser, Identity * id, Buffer * session_id2) pkalg = (char *) key_ssh_name(id->key); + /* DESCO: If we don't init the buffer now, freeing it will SEGV if we hit a goto user_auth_clean_exit */ + buffer_init(&b); + /* first test if this key is even allowed */ if(! pam_user_key_allowed(ruser, id->key)) goto user_auth_clean_exit; @@ -74,7 +77,6 @@ userauth_pubkey_from_id(const char *ruser, Identity * id, Buffer * session_id2) goto user_auth_clean_exit; /* construct packet to sign and test */ - buffer_init(&b); buffer_put_string(&b, sshbuf_ptr(session_id2), sshbuf_len(session_id2)); buffer_put_char(&b, SSH2_MSG_USERAUTH_TRUST_REQUEST);
When attaching the debug flag to the pam module, like below: # cat sudo #%PAM-1.0 auth sufficient /usr/lib64/security/pam_ssh_agent_auth.so file=/etc/security/authorized_keys debug auth include system-auth account include system-auth password include system-auth session optional pam_keyinit.so revoke session required pam_limits.so The following is produced in /var/log/secure, when attempting to sudo. Sep 22 13:59:46 localhost sudo[7679]: Beginning pam_ssh_agent_auth for user localuser Sep 22 13:59:46 localhost sudo[7679]: Attempting authentication: `localuser' as `localuser' using /etc/security/authorized_keys Sep 22 13:59:46 localhost sudo[7679]: Contacted ssh-agent of user localuser (1001) Sep 22 13:59:46 localhost sudo[7679]: trying public key file /etc/security/authorized_keys Sep 22 13:59:46 localhost sudo[7679]: auth_secure_filename: checking for uid: 0 Sep 22 13:59:46 localhost sudo[7679]: secure_filename: checking '/etc/security' Sep 22 13:59:46 localhost sudo[7679]: secure_filename: checking '/etc' Sep 22 13:59:46 localhost sudo[7679]: secure_filename: checking '/' Sep 22 13:59:46 localhost sudo[7679]: key not found Sep 22 13:59:46 localhost sudo[7679]: trying public key file /etc/security/authorized_keys Sep 22 13:59:46 localhost sudo[7679]: auth_secure_filename: checking for uid: 0 Sep 22 13:59:46 localhost sudo[7679]: secure_filename: checking '/etc/security' Sep 22 13:59:46 localhost sudo[7679]: secure_filename: checking '/etc' Sep 22 13:59:46 localhost sudo[7679]: secure_filename: checking '/' Sep 22 13:59:46 localhost sudo[7679]: key not found This bug is not present in pam_ssh_agent_auth-0.9.3-9.35 from RHEL 7.3. Workaround by downgrading the package, and perhaps using yum versionlock plugin.
*** Bug 1499884 has been marked as a duplicate of this bug. ***
I get this behaviour when ssh-agent offers a key which is not in the authorized-keys file. When I remove my _first_ key from the /etc/ssh/sudo_authorized_keys: [me@tiki_test:~]$ sudo su Segmentation fault tail -f /var/log/secure Oct 30 10:26:32 tiki_test sudo[29518]: trying public key file /etc/ssh/sudo_authorized_keys Oct 30 10:26:32 tiki_test sudo[29518]: auth_secure_filename: checking for uid: 0 Oct 30 10:26:32 tiki_test sudo[29518]: secure_filename: checking '/etc/ssh' Oct 30 10:26:32 tiki_test sudo[29518]: secure_filename: checking '/etc' Oct 30 10:26:32 tiki_test sudo[29518]: secure_filename: checking '/' Oct 30 10:26:32 tiki_test sudo[29518]: user_key_allowed: check options: 'ssh-rsa AAAAB3NzaC1y... Oct 30 10:26:32 tiki_test sudo[29518]: user_key_allowed: advance: 'AAAAB3NzaC1y... Oct 30 10:26:32 tiki_test sudo[29518]: key not found Adding the key back in fixes the problem: [me@tiki_test:~]$ sudo su [root@tiki_test]# tail -f /var/log/secure Oct 30 10:29:20 tiki_test sudo[29680]: trying public key file /etc/ssh/sudo_authorized_keys Oct 30 10:29:20 tiki_test sudo[29680]: auth_secure_filename: checking for uid: 0 Oct 30 10:29:20 tiki_test sudo[29680]: secure_filename: checking '/etc/ssh' Oct 30 10:29:20 tiki_test sudo[29680]: secure_filename: checking '/etc' Oct 30 10:29:20 tiki_test sudo[29680]: secure_filename: checking '/' Oct 30 10:29:20 tiki_test sudo[29680]: matching key found: file/command /etc/ssh/sudo_authorized_keys, line 1 Oct 30 10:29:20 tiki_test sudo[29680]: Found matching RSA key: SHA1:86:02:24:... Removing subsequent keys from the authorized_keys file does not trigger the bug for me. Only the checking a key which is loaded (as seen in ssh-add -L) but not in the /etc/ssh/sudo_authorized_keys. If there are loaded keys which are lower on the list and not in the file, the bug does not trigger. FYI I'm on SL7.3: cat /etc/redhat-release Scientific Linux release 7.3 (Nitrogen)
I can verify the problem the last poster says. The key is indeed in authorized_keys, but I get a coredump anyway (and 'no keys found'). I look forward to seeing it fixed :) I'm not sure if it's because it's the second key in my agent or not, but ...
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0980