RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1494268 - pam_ssh_agent_auth SEGV's if keyfile is missing
Summary: pam_ssh_agent_auth SEGV's if keyfile is missing
Keywords:
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:
: 1499884 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-21 21:35 UTC by Josip Vilicic
Modified: 2021-06-10 13:05 UTC (History)
9 users (show)

Fixed In Version: openssh-7.4p1-15.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 18:19:11 UTC
Target Upstream Version:
Embargoed:

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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:0980 0 None None None 2018-04-10 18:20:29 UTC

Description Josip 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.