bugzilla-daemon at mindrot.org
2002-Nov-01 15:40 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From michael_steffens at hp.com 2002-11-02 02:40 ------- Created an attachment (id=162) --> (http://bugzilla.mindrot.org/attachment.cgi?id=162&action=view) Patch: Workaround for pw change in privsep mode (3.5.p1) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2002-Nov-01 16:37 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From mouring at eviladmin.org 2002-11-02 03:37 ------- *** Bug 419 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2002-Nov-04 10:47 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From michael_steffens at hp.com 2002-11-04 21:47 ------- Created an attachment (id=163) --> (http://bugzilla.mindrot.org/attachment.cgi?id=163&action=view) Non-privsep pw change failure on HP-UX trusted systems Found why the password change dialog in non-privsep mode on a HP-UX 11.x trusted system fails when the user selects random password options. It's because OpenSSH's log function interferes with a log stub in /usr/lib/libsec.2: Program received signal SIGSEGV, Segmentation fault. 0xc00fadf0 in _doprnt+0x188 () from /usr/lib/libc.2 (gdb) bt #0 0xc00fadf0 in _doprnt+0x188 () from /usr/lib/libc.2 #1 0xc010b80c in vsnprintf+0x54 () from /usr/lib/libc.2 #2 0x4f94c in do_log (level=SYSLOG_LEVEL_INFO, fmt=0xcb000000 <Error reading address 0xcb000000: Bad address>, args=0x7f7f417c) at log.c:387 #3 0x4f20c in log (fmt=0xcb000000 <Error reading address 0xcb000000: Bad address>) at log.c:135 #4 0xc0164360 in passlen+0xa0 () from /usr/lib/libsec.2 #5 0xc1e8b2a4 in pwd_get_random+0x69c () from /usr/lib/security/libpam_unix.1 #6 0xc1e8ca28 in chauthtok_get_pwd+0x78 () from /usr/lib/security/libpam_unix.1 #7 0xc1e8139c in get_newpasswd+0x4a4 () from /usr/lib/security/libpam_unix.1 #8 0xc1e7f5fc in __update_authtok+0x30c () from /usr/lib/security/libpam_unix.1 #9 0xc1e7e6d0 in pam_sm_chauthtok+0xf8 () from /usr/lib/security/libpam_unix.1 #10 0xc06571b0 in pam_chauthtok+0x100 () from /usr/lib/libpam.1 #11 0x22660 in do_pam_chauthtok () at auth-pam.c:422 #12 0x2ea44 in do_login (s=0x40015fd0, command=0x0) at session.c:755 #13 0x2e594 in do_exec_pty (s=0x40015fd0, command=0x0) at session.c:616 #14 0x2e898 in do_exec (s=0x40015fd0, command=0x0) at session.c:709 #15 0x2df68 in do_authenticated1 (authctxt=0x4001cb90) at session.c:402 #16 0x2daec in do_authenticated (authctxt=0x4001cb90) at session.c:221 #17 0x16704 in main (ac=1, av=0x7f7e07f4) at sshd.c:1528 Renaming function log() to sshlog() in log.h resolves this conflict. See attached patch. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
Michael Steffens
2002-Nov-07 09:52 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
Darren Tucker wrote in http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=103658633821391 > This raises another possibility for changing passwords. > > As I see it the options now are: > > 1) Platform specific functions > Pro: RFC compliant > Con: extra code that runs as root That's what I would consider the clean solution. And for PAM it would even be only moderately platform specific. But I found it complicated, thus wrote ssh-chauthtok-helper and called it a workaround. > > 2) Spawn /bin/passwd in session > Pro: Simple, portable > Con: Not RFC compliant, possible timing attacks against proto 2? Agreed for non-PAM, but with PAM there arises an issue. (See below) One could consider ssh-chauthtok-helper the PAM-variant of this approach. > 3) Platform-specific setuid helpers > Pro: Consistent v1 & v2 interface, delegate policy to user-written > helpers, RFC compliant. > Con: Potential attacks against setuid programs, repeated code (eg > command line parsing). I think only two of them are required. The system native passwd program is already the suid helper for non-PAM, and for PAM one sshd specific helper can do the job. > > 4) Spawn /bin/passwd in tty (ala "expect") > Pro: portable? RFC compliant. > Con: lots of code, hard to get right, potentially flakey > > I know Markus doesn't like 1) and says that the only portable thing to > do is 2). Isn't this similar the the case for UseLogin? After all the > only portable way to do user authentication is /bin/login, but UseLogin > defaults to no and is considered depreciated, right? > > I'm still in favour of 1). The platform-specific change functions that > I've done so far[0] are ~40 lines (AIX) and ~100 lines (/etc/shadow). > The shadow function handles 3 platforms (Solaris, Redhat, UnixWare). This is only true for Solaris and Redhat (don't know about UnixWare) if sshd is not configured to use PAM for authentication! Otherwise it's calling for mismatches. In the view of PAM "passwd" and "sshd" are different services. The PAM modules configured for them do not need to be the same, and they do not need to be configured with the same parameters. A user could authenticate using one (set of) module(s), but then change password(s) with a different one, using passwd. > The > rest of the patches are required to check whether or not a password is > expired regardless of which method is used to change it. > > Regarding 3): if a consistent enough interface was specified you could > use the same setuid helper for PASSWD_CHANGEREQ during proto 2 > authentication as well as proto 1 sessions. > > Also, can someone who knows PAM please tell me if it's feasible to > implement a function like: > pam_change_password(char *user, char *oldpass, char *newpass)? > Or is some odd PAM module likely to render that impossible? It doesn't even need to be that odd :) Two things do make it impossible in general: - PAM allows to configure multiple modules (and passwords) to be required for a specific service. The pam_chauthtok() function will check them all, according to configuration. But how should that work with only these three arguments for pam_change_password() being given? - PAM is being given a conversation callback function on pam_start(), used for user interaction. How exactly dialogs are being performed is up to the modules then. As an example for an "odd" pw change dialog you may look at the HP-UX default when running in trusted mode: Changing password for dummy Old password: Last successful password change for dummy: NEVER Last unsuccessful password change for dummy: Wed Oct 23 08:35:45 2002 Do you want (choose one letter only): pronounceable passwords generated for you (g) a string of letters generated (l) ? to pick your passwords (p) ? Enter choice here: g Generating random pronounceable password for dummy The password, along with a hyphenated version, is shown. Hit <RETURN> or <ENTER> until you like the choice. When you have chosen the password you want, type it in. Note: type your interrupt character or `quit' to abort at any time. Password: kretavikuj Hyphenation: kret-av-ik-uj Enter password: Password: ruhizacnat Hyphenation: ru-hiz-ac-nat Enter password: Re-enter new password: Passwd successfully changed I would say it's impossible to encapsulate such dialogs using a function like you are suggesting, unless you restrict to option (p), and prepare for being presented the choice, of course. This is also the reason why I found it too complicated to implement the clean solution 1) for the moment. It would require to tunnel the entire conversation between session daemon and monitor, rather than just doing a request/response between these. Cheers! Michael
Reasonably Related Threads
- [Bug 423] Workaround for pw change in privsep mode (3.5.p1)
- [Bug 423] Workaround for pw change in privsep mode (3.5.p1)
- [Bug 423] New: Workaround for pw change in privsep mode (3.5.p1)
- [Bug 423] Workaround for pw change in privsep mode (3.5.p1)
- [Bug 423] Workaround for pw change in privsep mode (3.5.p1)