On Sat, 25 Oct 2003 02:40, Joe Moore wrote: > >> 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. > > How is ignoring/misusing/corrupting the seventh field "two bugs"?
Because the seventh field will not even be checked if the other checks are not passed. In the case of accounts such as "man" the shadow file does not have an entry that permits logging in, so the shell will not be checked for any login process unless there is some other bug. > >> 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. > > Your actual example is poor. First, it revolves around an extension to the > traditional Unix security model. PAM is an integral part of Debian, there is no option to not use it. > Second, your example relies specifically > on the "root" user having special security context privileges, and you do > not specify if a similar security vulnerability existed with other login > names. My example of a bug in my code used "root" as an example of exploiting it. In SE Linux the "root" identity can have very low privs, but the same result could be achieved by using the name of a priviledged identity in place of "root". > If the attacker of your buggy code had logged in as "bin" first (with the > wrong password), what security context was granted? I'd assume that it was > the default security context of that user (bin). Now, why should "bin" > have a special privileged security context? In the example of a bug in my code the "bin" identity gets no special privs. In the example of the PAM bug "bin" could login directly with no password. > If the attacker always gets the security context of the first login > attempt, then all privileged users should have invalid login shells > according to your logic. You're not suggesting we change root's shell to > /bin/false, are you? You are misunderstanding. I gave the example of a bug in my code related to an SE Linux login to demonstrate how easy it is to make a mistake in such things. I gave the example of the PAM bug to show how it has already been a problem in the past. > >> 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). > > Any attack or defect that overwrites/modifies that data structure is > capable of targetting either of them. I don't know of an example of such an attack, do you? I do know of an example of an attack that used to work which a shell of /bin/false would solve. > >> 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. > > I see no bugs in /bin/login where the userid is incorrectly assigned, nor > where the shell is incorrectly interpreted. That does not mean that there > are no bugs in /bin/login where one of these may be the case. This audit > comes with NO WARRANTY. Read my message again. Your message does not cover the same issue at all. -- 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]
