Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site ncrcae.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!mhuxj!mhuxr!ulysses!allegra!mit-eddie!genrad!decvax!mcnc!ncsu!ncrcae!wescott From: wescott@ncrcae.UUCP (Mike Wescott) Newsgroups: net.bugs.usg Subject: bug in /bin/login Message-ID: <2121@ncrcae.UUCP> Date: Fri, 1-Mar-85 13:55:12 EST Article-I.D.: ncrcae.2121 Posted: Fri Mar 1 13:55:12 1985 Date-Received: Mon, 4-Mar-85 04:48:40 EST Reply-To: wescott@ncrcae.UUCP (Mike Wescott) Organization: NCR, Columbia, SC Lines: 27 Keywords: login, nice 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