Bug 1494268
| Summary: | pam_ssh_agent_auth SEGV's if keyfile is missing | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Josip Vilicic <jvilicic> | ||||
| Component: | openssh | Assignee: | Jakub Jelen <jjelen> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Stefan Dordevic <sdordevi> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 7.4 | CC: | asakure, brywilharris, nmavrogi, prez, redhat-bugzilla, redhat, sdordevi, sean.alderman, szidek | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | openssh-7.4p1-15.el7 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2018-04-10 18:19:11 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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 |
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);