lane@SUMEX-AIM.STANFORD.EDU (Christopher Lane) (11/13/90)
Steve Hayman (sahayman@iuvax.cs.indiana.edu) sent me a note a week or so ago about a security flaw in the NeXT LoginWindow program. It seems that at Steve's site, like our own and others, they put a 'nologin', 'noshell', etc. entry for the 'shell' field in the passwd (of the NetInfo/YP master) file for (temporarily) defunct users. However, since LoginWindow doesn't care about the shell field, users with bogus shells were still able to login the NeXTs. Changing both the shell and password field for a user will completely lock them out--though this doesn't seem to be the standard practice. As a patch, as provided by Steve, I've generated a new version of MOTD that checks 'getusershell()' when used as a LoginHook and rejects users that don't have valid shells (as defined by getusershell and /etc/shells). Those using this new, more secure version of MOTD might want to make sure to add 'tcsh' to /etc/shells if you use that shell. I've FTP'd the new version of MOTD to the submissions directory of the cs.orst.edu NeXT archive. Let me know if there are problems with it, - Christopher -------
eps@toaster.SFSU.EDU (Eric P. Scott) (11/13/90)
In article <MailManager.658433850.4847.lane@ssrg-next-1.stanford.edu> lane@SUMEX-AIM.STANFORD.EDU (Christopher Lane) writes: >Steve Hayman (sahayman@iuvax.cs.indiana.edu) sent me a note a week or so ago >about a security flaw in the NeXT LoginWindow program. It seems that at >Steve's site, like our own and others, they put a 'nologin', 'noshell', etc. >entry for the 'shell' field in the passwd (of the NetInfo/YP master) file for >(temporarily) defunct users. However, since LoginWindow doesn't care about >the shell field, users with bogus shells were still able to login the NeXTs. "That's not a bug...that's a feature!" It's also old news. Here's a more interesting solution: Put together a NeXT Application to explain to the user why access has been disabled--you can do this entirely in Interface Builder if you like. Be creative! Then have it launched in place of the Workspace Manager: # su <username> % dwrite loginwindow Workspace /full/path/to/program % ^D (Yes, this really works!) For the passwd shell field, set it to run a "get lost" program, e.g.: const char sorry[]="\nAccess to this username has been suspended.\n\ Please contact ________ for assistance.\n\n"; main() { if (getppid()!=1) { (void)write(2, "Sorry\n", 6); _exit(1); } (void)write(2, sorry, (sizeof sorry)-1); (void)sleep(5); _exit(1); } This will take care of telnet/rlogin sessions. As long as the shell doesn't appear in /etc/shells, ftp will be locked out automatically. If the user had a .rhosts file, you probably want to rename it. Think about how you want to handle incoming mail! In any case, the problem isn't with the software--it's with the system administrator not thinking (probably the result of overeXposure to braindamaged window systems... :-) ). -=EPS=-