From owner-freebsd-security@FreeBSD.ORG Fri Aug 19 22:15:14 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80FAB16A420 for ; Fri, 19 Aug 2005 22:15:14 +0000 (GMT) (envelope-from smalone@udallas.edu) Received: from mail.udallas.edu (mail.udallas.edu [192.91.253.73]) by mx1.FreeBSD.org (Postfix) with SMTP id 23F3743D46 for ; Fri, 19 Aug 2005 22:15:13 +0000 (GMT) (envelope-from smalone@udallas.edu) Received: (qmail 1714 invoked from network); 19 Aug 2005 22:17:49 -0000 Received: from unknown (HELO ?10.3.20.101?) (10.3.20.101) by 0 with SMTP; 19 Aug 2005 22:17:49 -0000 Message-ID: <430659EF.2060202@udallas.edu> Date: Fri, 19 Aug 2005 17:15:11 -0500 From: "Sean P. Malone" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Security Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: pam_radius fail open? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: smalone@udallas.edu List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2005 22:15:14 -0000 Okay, I guess I’ll be the first to take Colin Percival up in that the following statement applies to me: “If you find a security problem -- or even if you find something which might possibly be a security problem but you're not certain if it is or not -- then please let us know.” I recently installed pam_radius according to the instructions located at the following address: https://www.freebsd.uwaterloo.ca/twiki/bin/view/Freebsd/PamRadius?shin=print.patern The instructions were very helpful. However, I’m not sure if I’ve mistakenly stumbled onto a fail open situation in that I’m fairly new to FreeBSD. Namely, while configuring /etc/pam.conf to validate SSH login credentials via radius against our existing Active Directory, I mistakenly typed the line for ssh as follows: ssh auth required pam_radius.so -update -/usr/local/etc/radius mistakenly thinking that one specifies the protocol as opposed to the daemon. Here is the result when I ssh in to the server from another host: login as: smalone Last login: Fri Aug 19 16:34:16 2005 from 10.3.20.101 Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-RELEASE (GENERIC) #0: Fri Mar 25 20:58:42 CST 2005 $ The thing to note is that the system did not prompt me for a password. I got right in to a shell prompt. Frightened, I then corrected the line to read: sshd auth required pam_radius.so -update -/usr/local/etc/radius and all worked as it should. I could ssh into the system using my AD password and the log file on the IAS server recorded a successful radius auth from the host. However, I then went back to the /etc/pam.conf file and commented out the ssh line all together resulting in a pam.conf that reads exactly as below: $ cat /etc/pam.conf # # $FreeBSD: src/etc/pam.d/sshd,v 1.15 2003/04/30 21:57:54 markm Exp $ # # PAM configuration for the "sshd" service # # auth #sshd auth required pam_radius.so -update -/usr/local/etc/radius #auth required pam_nologin.so no_warn #auth sufficient pam_opie.so no_warn no_fake_prompts #auth requisite pam_opieaccess.so no_warn allow_local #auth sufficient pam_krb5.so no_warn try_first_pass #auth sufficient pam_ssh.so no_warn try_first_pass #auth required pam_unix.so no_warn try_first_pass # account #account required pam_krb5.so #account required pam_login_access.so #account required pam_unix.so # session #session optional pam_ssh.so #session required pam_permit.so # password #password sufficient pam_krb5.so no_warn try_first_pass #password required pam_unix.so no_warn try_first_pass $ Basically, it’s an empty file as far as pam_radius knows. Then I tried once more to ssh in to the server and was, once again, let in without being prompted for a password. Thus, would it not only require someone to merely know the name of one of your users (such as an email username on an email host) to get a shell? Is this a fail open? Regards, Sean Malone