Bug 1494268 - pam_ssh_agent_auth SEGV's if keyfile is missing
Summary: pam_ssh_agent_auth SEGV's if keyfile is missing
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssh
Version: 7.4
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jakub Jelen
QA Contact: Stefan Dordevic
URL:
Whiteboard:
Keywords:
: 1499884 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-21 21:35 UTC by Jo Vilicic
Modified: 2018-04-10 18:20 UTC (History)
9 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-04-10 18:19:11 UTC


Attachments (Terms of Use)
patch from customer to handle lack of a keyfile (1023 bytes, patch)
2017-09-21 21:35 UTC, Jo Vilicic
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:0980 None None None 2018-04-10 18:20 UTC

Description Jo Vilicic 2017-09-21 21:35:58 UTC
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);

Comment 4 salderman@stellarinnovations.com 2017-09-22 18:12:53 UTC
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.

Comment 6 Jakub Jelen 2017-10-18 12:59:37 UTC
*** Bug 1499884 has been marked as a duplicate of this bug. ***

Comment 8 brywilharris@gmail.com 2017-10-30 14:39:17 UTC
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)

Comment 10 Preston A Elder 2017-11-16 16:41:47 UTC
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 ...

Comment 14 errata-xmlrpc 2018-04-10 18:19:11 UTC
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


Note You need to log in before you can comment on or make changes to this bug.