moyman@ORCHESTRA.ECN.PURDUE.EDU (James M Moya) (09/08/90)
Much to my dismay, if you have any UNIX accounts with nothing in the /etc/passwd "password" field, you can "connect" to that account through aufs (just use the login of that account in the chooser when "aufs connecting", and hit return) voila! full access!! ...This can cause potential (let your imagination run here) damage. Here is a quick aufs fix I put in that should do the job... In afpos.c: >> break; >> case UAM_CLEAR: >> if (!apasswdfile) { >> p = (struct passwd *) getpwnam(nam); /* user name */ >> if (p == NILPWD) { >> log("Login: Unknown user %s",nam); >> return(aeParamErr); /* unknown user */ >> } **** if (*p->pw_passwd == NULL) { **** log("Unauthorized access: you can NOT connect to this account."); **** return(aeUserNotAuth); **** } >> if (strcmp(crypt(pwd,p->pw_passwd),p->pw_passwd) != 0) { >> log("Login: Incorrect password for user %s",nam); >> if (!safedebug) >> return(aeUserNotAuth); >> } >> } else { Mike Moya Engineering Computer Network Purdue University
rapatel@khnphwzhn.njin.net ( Rakesh Patel) (09/08/90)
This fix was done in the Rutgers cap distribution a while ago, but note also that it needs to be done within the DES encyrption version as well (used when using the alternate password file). That part isn't in the Rutgers distribution, so those using the alternate password file on Suns, where it uses DES encryption should make sure no non-passworded entries are within that alternate password file. Rakesh Patel.
bin@primate.wisc.edu (Brain in Neutral) (09/10/90)
From article <9009072101.AA15458@orchestra.ecn.purdue.edu>, by moyman@ORCHESTRA.ECN.PURDUE.EDU (James M Moya): > > Much to my dismay, if you have any UNIX accounts with nothing in the > /etc/passwd "password" field, you can "connect" to that account through > aufs (just use the login of that account in the chooser when "aufs connecting", > and hit return) voila! full access!! ...This can cause potential (let your > imagination run here) damage. Why is this an *aufs* problem? If you have an account with no password, anyone can login to that account via modem, hardwired terminal, terminal server, telnet, ftp, etc. and have full access. That's what "no password" means - it's a public account, essentially. Your password file is broken, not aufs. Paul DuBois dubois@primate.wisc.edu
smart@mel.dit.csiro.au (Robert Smart) (09/10/90)
In article <3065@uakari.primate.wisc.edu> bin@primate.wisc.edu writes: > >Why is this an *aufs* problem? If you have an account with no password, >anyone can login to that account via modem, hardwired terminal, terminal >server, telnet, ftp, etc. and have full access. That's what "no password" >means - it's a public account, essentially. > >Your password file is broken, not aufs. > Accounts without passwords are supposedly meant for specialized harmless things. Some machines have an account sync which has /bin/sync in the shell field. The correct approach seems to be (a) there should be a standard routine for checking a name/password combination; and (b) that routine should check the shell field in /etc/passwd against a list of interactive shells -- /etc/shells in SunOS 4.x. Usernames with other shells there shouldn't get access except for the purpose of running the named program. The parameters to the access checking program would be username, password and program to run. CAP could then call it like this: check_access(name,pwd,"AUFS") and this would allow access if the password was empty and the shell field for the user was AUFS. This would allow access to a sort of anonymous AUFS account that had AUFS in the shell field. This could be handy. However given the number of things like CAP which assume that all users in /etc/passwd are real users it is not a good idea to have usernames like sync with no password and a supposedly harmless shell. Bob Smart
djh@cs.mu.oz.au (David Hornsby) (09/10/90)
From article <9009072101.AA15458@orchestra.ecn.purdue.edu>, by James M Moya: > Much to my dismay, if you have any UNIX accounts with nothing in the > /etc/passwd "password" field, you can "connect" to that account ... With certain provisos, there is another solution that needs no new code. If your unprotected account has a passwd entry that provides a non-shell executable and the home directory points somewhere sensible, IE: a dummy directory for nonhumans (which shouldn't be owned by the dummy account!), create a .afpvols file with just a blank line. This works providing that there is a valid global afpvols file. Users of the unprotected account get to see only the global volumes (which naturally have the desired permissions to prevent write access etc.). - David.
phil@Shiva.COM (Phil Budne) (09/25/90)
From: moyman@orchestra.ecn.purdue.edu (James M Moya)
Subject: aufs security warning/fix
Message-ID: <1990Sep7.223126.13757@Shiva.COM>
Much to my dismay, if you have any UNIX accounts with nothing in
the /etc/passwd "password" field, you can "connect" to that
account through aufs (just use the login of that account in the
chooser when "aufs connecting", and hit return) voila! full
access!! ...This can cause potential (let your imagination run
here) damage.
Here is a quick aufs fix I put in that should do the job...
Hmm... and I always thought it was a feature! (or a bug in your passwd
file). My vote is to check the shell;
>> case UAM_CLEAR:
>> if (!apasswdfile) {
>> p = (struct passwd *) getpwnam(nam); /* user name */
>> if (p == NILPWD) {
>> log("Login: Unknown user %s",nam);
>> return(aeParamErr); /* unknown user */
>> }
if (p->pw_passwd == NULL || p->pw_passwd[0] == '\0' ) {
char *sp;
int found;
found = 0;
if( p->pw_shell != NULL ) {
setusershell();
while( !found && (sp = getusershell()) != NULL )
if( strcmp( p->pw_shell, sp ) == 0 )
found = 1;
}
endusershell();
if( !found ) {
log("Unauthorized access: bad shell %s", p->pw_shell);
return(aeUserNotAuth);
} /* not found */
} /* no password */
For the un-4.3-ized; getusershell() returns the lines of the file
/etc/shells. If /etc/shells does not existq it returns "/bin/sh" and
"/bin/csh"
............o
Philip Budne . o---+----o Shiva Corporation
. o | 1 Cambridge Center
Internet: phil@Shiva.COM . Shiva | Cambridge, Ma 02142
. | Tel (617) 864-8500
(formerly budd@bu-it.bu.edu) . o---o Fax (617) 252-6852