Path: utzoo!attcan!uunet!husc6!encore!bzs
From: bzs@Encore.COM (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Re: Password security - Another idea
Message-ID: <4613@xenna.Encore.COM>
Date: 7 Jan 89 20:41:52 GMT
References: <228@sea375.UUCP> <4497@xenna.Encore.COM> <4523@xenna.Encore.COM> <27283@ucbvax.BERKELEY.EDU> <4546@xenna.Encore.COM> <27361@ucbvax.BERKELEY.EDU>
Organization: Encore Computer Corp, Marlboro, MA
Lines: 93
In-reply-to: marc@ucbvax.BERKELEY.EDU's message of 5 Jan 89 10:55:13 GMT
Posting-Front-End: GNU Emacs 18.41.15 of Tue Jun  9 1987 on xenna (berkeley-unix)


Marc Teitelbaum writes...well, first, quotes...

In article <4546@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes:
>
>Round and round, and you're not disturbed at the fact that you're now
>...

Uh, is this supposed to be a fair summary of my article? (quote quoted
in entirety.) Anyhow...

>The first problem I have with your argument is essentially this.  You
>assume that file system security is weak enough that an average
>hacker can gain access to the shadow password file.  I contend that
>if the average hacker can accomplish this, then he doesn't *need*
>to crack any passwords because he can *just* as easily gain access
>to any other file in the filesystem.

Excellent point, deserves an answer.

Most importantly I claim that a shadow password file only requires
READ access to the file system while cracking a password (particularly
system passwords) gives one WRITE access to the system. We must
distinguish those two concepts, particularly in this case since all
we're claiming is that a shadow password affects the readability of
password encryptions.

In that context I make two claims:

1. That read access breaches are easier to come by than write access
breaches and much harder to detect.

The reason they're easier to come by is mere practice, I can't prove
it. Programs which only read files seem to be less thoroughly checked
for holes and I know of a few such programs which I've seen reported.
The typical pattern is a program running priv'd which reports some
sort of system or user status and can be made, via a symlink or hard
link, to be fooled into reading a different file and dumping it to the
user's terminal (for capture) or redirected to a file (same thing.)

As a hypothetical example one could imagine linking a $HOME/.netrc to
this /etc/shadow file and then the encryptions pouring out of a
program trying to read the .netrc as syntax errors, that kind of
thing. It's one of the oldest tricks in the book (I remember years ago
on a Multics system someone getting a file for me, inadvertantly left
unreadable [I had a note from the author telling me to come by for a
tape of the program, he wasn't around] by simply including it in a
mail file indirectly and mailing it to myself.) Those holes usually
don't work for write access.

2. If you get write access to the file system you have to change
something. Although it's a major problem and can be exploited
mercilessly it can be generally checked for by compares with backup
copies, how do you check for unauthorized reading? On the current
system you can't (access times don't help since legitimate accesses
keep updating that every few minutes anyhow.) You have absolutely no
way of telling me at any point in time whether someone has walked away
with a copy of the shadow file today. At best you can hem and haw and
say it doesn't matter. You can tell me (assuming some sort of backup)
whether someone changed the pw file today.

I suppose the real problem I am alluding to is you've admitted a way
to turn global read access into global write access as a target. I
think we'd better off closing the original hole than simply moving it
down a level in the hierarchy, temporarily.

After all, if you don't believe you've left the danger present then
why bother protecting it?

So, the answer, put simply, is because read access can now get me
write access.

>The second problem with your argument is that you overlook Henry's
>point that no security is perfect, just that the more secure
>system makes it that much *harder* to break in.  Puts up more road
>blocks.  Leaves more trails for the careless. - Your argument is
>that the perceived security of shadow password files will make the
>system administrator more complacent, therefore it's undesireable.

Agreed, but my point is not that it makes the sysadmin complacent,
it's that it makes the system DESIGNER complacent.

Put another way, if you have a way planned that makes passwords secure
even if someone (eg. a stupid employee) manages to walk out with a
copy of your pw file then let's trashcan the shadow password file in
the first place and just use that. If you don't then I have to claim
that the system designers are in fact complacent (almost by
definition) and my argument stands.

Or, in one sentence, let's deal with the real problem and stop trying
to sweep it under the rug.

	-Barry Shein, ||Encore||