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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]