wescott@ncrcae.UUCP (Mike Wescott) (03/01/85)
Looking throught the code (SysVr2) for /bin/login the other day I saw an interesting piece of code. As soon as the username is found in /etc/passwd login examines the gcos field (comments field) for an initial string of "pri=". If found the following (signed) integer is used in a nice() call, changing the nice value BEFORE the passwd is validated. I can see some minor possibilities in using this "feature" but if there is anyone in the passwd file with a negative increment ANYONE can use it by first using the wrong username, then any passwd, then use your own login/passwd and voila a higher priority shell. The bug, a mentioned in the first paragraph is that the gcos field is checked and nice() called BEFORE the passwd is validated, hence the new nice value takes effect for anyone who uses the login name even without getting the passwd right. This is no real problem if there are no negative values in the passwd file. If there are negative values multiple consecutive attempts can increase priority to the max. The fix is simple - move the code out of the loop and put it after the passwd validation. Mike Wescott NCR Corp. mcnc!ncsu!ncrcae!wescott usceast!ncrcae!wescott
rick@sesame.UUCP (Rick Richardson) (03/03/85)
> Looking throught the code (SysVr2) for /bin/login the other day > I saw an interesting piece of code. As soon as the username is > found in /etc/passwd login examines the gcos field (comments field) > for an initial string of "pri=". If found the following (signed) > integer is used in a nice() call, changing the nice value BEFORE > the passwd is validated. > ... > Mike Wescott This isn't the only possible way to circumvent the "pri" field. I find it quite nice on systems that let you either "newuser" or change your "gcos" field at will. My name becomes "pri=-20 Rick Richardson". But don't tell too many people about this. I wouldn't want it to go away! -Rick Richardson PC Research, Inc.