From owner-freebsd-security@FreeBSD.ORG Tue Nov 15 21:12:48 2011 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D1DF1065674 for ; Tue, 15 Nov 2011 21:12:48 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3C9978FC13 for ; Tue, 15 Nov 2011 21:12:48 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 597A257A1; Tue, 15 Nov 2011 21:12:47 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 374458E8E; Tue, 15 Nov 2011 22:12:47 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Guy Helmer References: <98001F9B-0B96-4D17-9EAE-08B12A1C1C75@palisadesystems.com> Date: Tue, 15 Nov 2011 22:12:46 +0100 In-Reply-To: <98001F9B-0B96-4D17-9EAE-08B12A1C1C75@palisadesystems.com> (Guy Helmer's message of "Tue, 15 Nov 2011 10:39:31 -0600") Message-ID: <86ty65qecx.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: freebsd-security@freebsd.org Subject: Re: Possible pam_ssh bug? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 21:12:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Guy Helmer writes: > I have a shell user who is able to login to his accounts via sshd on > FreeBSD 8.2 using any password. The user had a .ssh/id_rsa and > .ssh/id_rsa.pub key pair without a password but nullok was not > specified, so I think this should be considered a bug. It turns out that this goes all the way to OpenSSL, which ignores the passphrase if the key is not encrypted. The only solution I can think of - more of a workaround, really - is to first try to load the key with an empty passphrase, and skip the key if that worked. See the attached (untested) patch. A more advanced patch would load all keys but require at least one of them to have a passphrase. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=pam_ssh_nullok.diff Index: lib/libpam/modules/pam_ssh/pam_ssh.c =================================================================== --- lib/libpam/modules/pam_ssh/pam_ssh.c (revision 227125) +++ lib/libpam/modules/pam_ssh/pam_ssh.c (working copy) @@ -93,7 +93,8 @@ * struct pam_ssh_key containing the key and its comment. */ static struct pam_ssh_key * -pam_ssh_load_key(const char *dir, const char *kfn, const char *passphrase) +pam_ssh_load_key(const char *dir, const char *kfn, const char *passphrase, + int nullok) { struct pam_ssh_key *psk; char fn[PATH_MAX]; @@ -103,6 +104,21 @@ if (snprintf(fn, sizeof(fn), "%s/%s", dir, kfn) > (int)sizeof(fn)) return (NULL); comment = NULL; + if (!nullok) { + /* + * If the key is unencrypted, OpenSSL ignores the + * passphrase, so it will seem like the user typed in the + * right one. This allows a user to circumvent nullok by + * providing a dummy passphrase. Verify that the key + * really *is* encrypted by trying to load it with an + * empty passphrase. + */ + key = key_load_private(fn, "", &comment); + if (key != NULL) { + key_free(key); + return (NULL); + } + } key = key_load_private(fn, passphrase, &comment); if (key == NULL) { openpam_log(PAM_LOG_DEBUG, "failed to load key from %s", fn); @@ -180,7 +196,7 @@ /* try to load keys from all keyfiles we know of */ for (kfn = pam_ssh_keyfiles; *kfn != NULL; ++kfn) { - psk = pam_ssh_load_key(pwd->pw_dir, *kfn, passphrase); + psk = pam_ssh_load_key(pwd->pw_dir, *kfn, passphrase, nullok); if (psk != NULL) { pam_set_data(pamh, *kfn, psk, pam_ssh_free_key); ++nkeys; --=-=-=--