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

[Julie]

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, 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.

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.

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.

>> 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.