hoey@NRL-AIC.arpa (Dan Hoey) (10/17/86)
Date: Mon, 25 Aug 86 11:15:24 edt
From: sscalsk@nswc-wo.arpa
Anybody ever had a blank line as the first line in your password
file? It happened to me a few weeks ago and the system would not
let any user at all log on. Su did not work either....
At least in vanilla 4.2, having blank lines anywhere in your password
file opens a security hole that I will forbear to discuss on this list.
I have not verified this on other systems, but I advise you to stick to
the standard format. If you want to insert blank lines for readability
(which is how I discovered the bug) use nearly-blank lines like
x:*:0:0: ::
assuming that "x" is not a user on your system.
Dan Hoey
hoey@NRL-AIC.ARPAmcvoy@rsch.WISC.EDU (Lawrence W. McVoy) (10/21/86)
In article <4701@brl-smoke.ARPA> hoey@NRL-AIC.arpa (Dan Hoey) writes: >At least in vanilla 4.2, having blank lines anywhere in your password >file opens a security hole that I will forbear to discuss on this list. >I have not verified this on other systems, but I advise you to stick to >the standard format. If you want to insert blank lines for readability >(which is how I discovered the bug) use nearly-blank lines like > >x:*:0:0: :: Umm, could be sort of a security hole in itself: if anyone can make a a match to the "*" you have let them enter the system as root (uid==0). I realize that "*" and "**" etc are commonly used and probably pose no risk on most [all?] versions of Unix, but why tempt fate? Make the uid & gid be something harmless and be sure. -- Larry McVoy mcvoy@rsch.wisc.edu, {seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy "They're coming soon! Quad-stated guru-gates!"
steiny@scc.UUCP (Don Steiny) (10/21/86)
In article <2837@rsch.WISC.EDU>, mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes: > > use nearly-blank lines like > > > >x:*:0:0: :: > > Umm, could be sort of a security hole in itself: if anyone can make a > a match to the "*" you have let them enter the system as root (uid==0). I am sure many people will point this out, but '*' represents the ENCRYPTIFIED password, which must have a two character key and thus be at least 3 characters. There is no possiblity of '*' ever being a password. -- scc!steiny Don Steiny @ Don Steiny Software 109 Torrey Pine Terrace Santa Cruz, Calif. 95060 (408) 425-0382
guy@sun.UUCP (10/21/86)
> Umm, could be sort of a security hole in itself: if anyone can make a > a match to the "*" you have let them enter the system as root (uid==0). No, it can't, because they can't. Remember, the password stored in "/etc/passwd" is an *encrypted* password, and the password check is done by encrypting the password the user types (or, more correctly, encrypting a constant string using the password as key) and comparing it with the encrypted password from "/etc/passwd". The System V manual explicitly states that the encrypted password is 13 characters long and will not contain any characters other than ".", "/", letters, or numbers. This is also true of other UNIX systems, since they use the same encryption software. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
tim@brspyr1.UUCP (Tim Northrup) (10/24/86)
In article <2837@rsrch.WISC.EDU> mcvoy@rsch.wisc.edu (Larry McVoy) writes: > In article <4701@brl-smoke.ARPA> hoey@NRL-AIC.arpa (Dan Hoey) writes: > >At least in vanilla 4.2, having blank lines anywhere in your password > >file opens a security hole that I will forbear to discuss on this list. > >I have not verified this on other systems, but I advise you to stick to > >the standard format. If you want to insert blank lines for readability > >(which is how I discovered the bug) use nearly-blank lines like > > > >x:*:0:0: :: > > Umm, could be sort of a security hole in itself: if anyone can make a > a match to the "*" you have let them enter the system as root (uid==0). > I realize that "*" and "**" etc are commonly used and probably pose > no risk on most [all?] versions of Unix, but why tempt fate? Make the > uid & gid be something harmless and be sure. I was under the impression that the /etc/passwd table used crpyt(3) style passwords, and that the password generated was ALWAYS 13 characters long. If this is still the case, it is IMPOSSIBLE to generate a password that matches '*'. (We use it for all of our secure ID's). -- Tim Northrup (518) 783-1161 BRS Information Technologies ...!ihnp4!dartvax!brspyr1!tim 1200 Route 7 ...!seismo!rpics!brspyr1!tim Latham, NY 12110 tim@brspyr1.UUCP ======== INSERT STANDARD DISCLAIMER FORM 43Z892-BXY/86.3 HERE ============= "It's good to be the king!"
eric@cti.UUCP (Eric Black) (10/25/86)
In article <8352@sun.uucp> guy@sun.uucp (Guy Harris) writes: >[somebody wrote, I could go back and find who, but I'm lazy]: >> Umm, could be sort of a security hole in itself: if anyone can make a >> a match to the "*" you have let them enter the system as root (uid==0). > >No, it can't, because they can't. Lots of similar mail messages and articles to come, no doubt. I always thought it was obvious, but enough people have expressed "ah-ha!"- type wonder at this that maybe it bears repeating, and now's a good time. There is always an amount of turnover at universities and companies, and user accounts need to be zapped and/or de-activated. Many times, however, the *files* owned by those folks, in those directories, want to remain; there are also occasions where it is desirable to temporarily prevent a user or account from logging in. A superuser (or adequately privileged user) can zap the user's password, either with the passwd command or by editing the /etc/passwd file, but since there is "no" way to determine a user's password from the encrypted form in /etc/passwd, it's hard to set it back. A convenient method is to edit the passwd file and insert some character at the beginning of the password string. I like to use '%', because it is one of the characters that is never generated in an encryption string and is easy to find and edit out later. A password can NEVER be entered which matches the user's (new) password, preventing logins (and su's other than by root), yet it is easy to give that person his/her password back. A trivial point, to be sure, but I thought it was obvious and it apparently isn't. -- Eric Black "Garbage In, Gospel Out" UUCP: {sun,pyramid,hplabs,amdcad}!cti!eric
chris@umcp-cs.UUCP (Chris Torek) (10/30/86)
>In article <4701@brl-smoke.ARPA> hoey@NRL-AIC.arpa (Dan Hoey) writes: >>At least in vanilla 4.2, having blank lines anywhere in your password >>file opens a security hole that I will forbear to discuss on this list. >>... If you want to insert blank lines for readability (which is >>how I discovered the bug) use nearly-blank lines like >> >>x:*:0:0: :: In article <2837@rsch.WISC.EDU> mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes: >Umm, could be sort of a security hole in itself. . . . Not as bad as the original blank-line problem. In fact, if you insert a line of the form :*:0:0::: near the top of the file, this provides an ugly sort-of-workaround to the original problem. The *real* problem is that the C library getpwent() routine is not careful, and that passwd is not careful about getpwent(). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu