Re: Why do system users have valid shells
On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
> > There was a case of a buggy pam some time ago which let people login to
> > accounts such as "man" and "bin". Changing the shell would have
> > prevented that problem (or limited the number of accounts that were
> > vulnerable)
>
> So there was a bug in the PAM code so that it ignored an invalid
> /etc/passwd field. Why would the next bug not ignore some other
> /etc/passwd field (like the user's chosen shell)?
You are correct, the next time a problem is discovered in PAM there could be
two bugs not one. But it's more likely that bugs will be discovered one at a
time.
> >> (and thus write access to /etc/passwd and/or the chsh command)
> >
> > That does not follow. If a program can be tricked into logging you in
> > as the wrong account, that does not mean that it's actions can give
> > any result other than that of an authorised user logging in to that
> > account.
>
> It is as likely as some other bug in the privileged process.
You really should read the source for /bin/login, or even better try patching
it yourself some time. Then you would get a better idea of what the issues
are.
> I realize this particular example is probably not intended to demonstrate
> the value of /bin/false as a shell, but it's hard to discuss a hypothetical
> bug...
Which is why I gave an actual example of a PAM bug.
> > A similar bug could once again be discovered in /bin/login (if you
> > doubt then please audit the source ;).
>
> If a similar bug existed in /bin/login, it sounds like it would behave
> this way:A user tries username: bin with the wrong password. The user then
> types their username (bob) and password (1234), and are given a UID2 shell
> of /bin/sh. (thus a different UID than specified in the /etc/passwd file
> for bob, _and_ a different shell than specified for bob)
>
> Your claim is that by changing bin(UID 2)'s shell to /bin/false, this
> hypothetical bug is more difficult to exploit.
Yes, the UID and the shell are stored in the same data structure, see
getpwent(3).
> And that the analogous bug where bob's shell is respected (giving him a
> UID2 shell of /bin/csh) is unlikely.
Yes. Read the code.
> >> * A more important consideration is the location of "bin"'s $HOME.
> >
> > What's wrong with the current location?
>
> At the moment, nothing. Since write access to /bin pretty much 0wns the
> box. But a .rhosts file (+) in /bin might not be noticed for a while. A
> file in /var/empty (the home dir for sshd's privsep user) might be noticed.
To create a file in /bin you need root access. Therefore to create
/bin/.rhosts you need more access than such a file will grant. There is no
point in such an attack. Why would someone create /bin/.rhosts when they can
create /root/.rhosts?
Does bin even own ANY files or have write access to ANY directories on a
default install? From a quick look it seems that account "bin" gets no write
access to anything on a Linux system.
> I guess what I'm saying is that there are just as many ways to get access
> to UID2 with "bin:x:2:2:bin:/bin:/bin/false" in the /etc/passwd. As there
> are with "bin:x:2:2:bin:/bin:/bin/sh".
Name some examples.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Reply to: