Re: Why do system users have valid shells
Russell Coker said:
> 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.
How is ignoring/misusing/corrupting the seventh field "two bugs"?
>> 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. 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.
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?
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?
>> > 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).
Any attack or defect that overwrites/modifies that data structure is capable
of targetting either of them.
>
>> 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.
--Joe
Reply to: