[Pkg-shadow-devel] Bug#531341: Debian bug 531341

[Goswin von Brederlow]

"Julie" <tallgirl at austin.rr.com> writes:

> From: "Goswin von Brederlow" <goswin-v-b at web.de>
>> Nicolas François <nicolas.francois at centraliens.net> writes:
>>> On Mon, Jul 20, 2009 at 02:01:27PM -0500, tallgirl at austin.rr.com wrote:
>>>>
>>>> I think that you're confusing the requirement that unknown user names
>>>> not be logged, because they might be a user's password with the
>>>> non-existent requirement that all unknown user names be treated like
>>>> "root" and not prompted for a password.
>>>
>>> No, I was not mentioning the case where an user types her password
>>> instead
>>> of her username.
>>>
>>>> If you still think you're right, I'd like to see the source for the
>>>> requirement.  I've been through a number of formal evaluations as the
>>>> vendor lead (IBM) and we never had that requirement under any evaluation
>>>> scheme.
>>>
>>> I cannot point you to any source of requirements, except mine:
>>>  1. root's password should not be transmitted on insecure lines
>>>     => The password should not be prompted if login is on an
>>> insecure line
>>>        and login thinks the user might be root.
>>>  2. root can mistype her username
>>>     => Any invalid user might be a mistyped "root"
>>
>> You can run some heuristic:
>> 1) if user exists and is not root then it is probably not mistyped
>> 2) if user is similar to root (like rot) then assume mistyped
>> 3) assume normal user otherwise
>
> What do you do when "rot", "roto", "rott", et alia, exist?  Again,

As said a few lines later that is the problem of root. Alowing user
names that are easily mistypes of root compromises the
heuristic. Don't do that. One can only do so much.

> you're leaking user name information and leaving the system open to a
> (slightly more limited) User Enumeration attack.  In a real
> evaluation, which is the claimed justification for this behavior, you
> don't get to slack off on one requirement to make up for another.
>
>> If root mistypes his user name as kfgerjhfgsdgfvedj I think then we
>> can blame root itself. Same if root allows a user rot to be created
>> and then mistypes his name. In the end the user name is clearly
>> visible. Watch what you type.
>
> The user name in only visible to the user and anyone sniffing the
> connection.  Since the user knows what they've typed, that leaves
> packet sniffers.  Conveniently the problem at hand is one of a
> legitimate root user entering their password and having it sniffed.
> This leaves two choices --
>
> 1). You prevent the packet sniffer from knowing, with certainty, that
> they have the correct root password, by denying access, regardless of
> the password.

Which you do in any case.

> 2). You prevent the packet sniffer from having an opportunity to sniff
> the packet by refusing the connection.  While this satisfies Nicholas'
> requirement, it fails on Human Factors because users tend to type
> their name and password in very quick succession.  Which now results
> in the password being in the "user name" location in the sign on
> dialog.

Well, usualy an unsecure line will be something like a telnet
connection. In which case it would detect an attempt to log in as root
and kill the connection. Even if the user enters the root password it
would not be transmitted as there would be no password prompt.

And typing your password too fast is bad in any case. If you start
typiong it before the password prompt turns off echo it ends up on the
console as clear text even for a local login. There is no guard
against stupidity.

> In either instance, the layered security of the system protects itself
> --
> unless the attacker has access to a secure TTY, they can get a million
> root passwords and they will still be denied access.
>
>>>  3. login should not leak information about the valid usernames on the
>>>     system.
>>>     => The user should be prompted a password whether the username
>>> is valid
>>>        or not.
>>
>> We all know there is a root user already so no information is leaked. :)
>
> Not at all -- there are protection profiles where the privileged user
> must have the ability to change their name.  In those profiles, the
> name of the super-user is considered to be privileged information, and
> having it be public by making it "root" violates the profile.

If you are that paranoid then you should not have any insecure lines
at all. So the whole point about preventing root logins on insecure
lines becomes mood.

>>> I do not think those requirements can be satisfied at the same time.
>>
>> But near enough.
>
> Well ... I think what's being described is Security Through Obscurity.
> I'd still like to see a protection profile which requires the
> described behavior.  As it stands, the alternatives all permit a User
> Enumeration attack of some form or another.
>
> -- Julie.

I think preventing a root login on an insecure line from even asking
for a password is a good idea. The exposure of the transmitted
password is a far greater thread than exposing that the system will
not allow "root" to login on the insecure line.

Note that 99.999% of linux systems will have a root user so only
0.001% are "hurt" by exposing the fact. On the other hand 100% of the
systems don't want the root password exposed to the world.

MfG
        Goswin