Debian Bug report logs - #531341
prints "login incorrect" without asking for password when entering an invalid login

version graph

Package: login; Maintainer for login is Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>; Source for login is src:shadow.

Reported by: Dmitri Gribenko <gribozavr@gmail.com>

Date: Sun, 31 May 2009 18:30:02 UTC

Severity: normal

Found in version shadow/1:4.1.3.1-1

Fixed in version shadow/1:4.1.4.2+svn3283-1

Done: Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, gribozavr@gmail.com, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>:
Bug#531341; Package login. (Sun, 31 May 2009 18:30:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitri Gribenko <gribozavr@gmail.com>:
New Bug report received and forwarded. Copy sent to gribozavr@gmail.com, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>. (Sun, 31 May 2009 18:30:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Dmitri Gribenko <gribozavr@gmail.com>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: prints "login incorrect" without asking for password when entering an invalid login
Date: Sun, 31 May 2009 21:27:09 +0300
Package: login
Version: 1:4.1.3.1-1
Severity: normal


If you enter an invalid login, you get "login incorrect" immediately.  Expected
behavior is that password should be asked regardless of login correctness.
This is to mitigate user enumeration attacks.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-rc7-3218911f-30may2009 (SMP w/2 CPU cores)
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages login depends on:
ii  libc6                         2.9-12     GNU C Library: Shared libraries
ii  libpam-modules                1.0.1-9    Pluggable Authentication Modules f
ii  libpam-runtime                1.0.1-9    Runtime support for the PAM librar
ii  libpam0g                      1.0.1-9    Pluggable Authentication Modules l

login recommends no packages.

login suggests no packages.

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>:
Bug#531341; Package login. (Mon, 01 Jun 2009 06:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christian Perrier <bubulle@debian.org>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>. (Mon, 01 Jun 2009 06:18:02 GMT) Full text and rfc822 format available.

Message #10 received at 531341@bugs.debian.org (full text, mbox):

From: Christian Perrier <bubulle@debian.org>
To: Dmitri Gribenko <gribozavr@gmail.com>, 531341@bugs.debian.org
Subject: Re: [Pkg-shadow-devel] Bug#531341: prints "login incorrect" without asking for password when entering an invalid login
Date: Mon, 1 Jun 2009 08:14:35 +0200
[Message part 1 (text/plain, inline)]
Quoting Dmitri Gribenko (gribozavr@gmail.com):
> Package: login
> Version: 1:4.1.3.1-1
> Severity: normal
> 
> 
> If you enter an invalid login, you get "login incorrect" immediately.  Expected
> behavior is that password should be asked regardless of login correctness.
> This is to mitigate user enumeration attacks.

login uses PAM for this and defaults settings are correct wrt brute
force attackes, with a 3 seconds delay before answering "Login incorrect".

Please check your /etc/pam.d/login file, it's probably missing a line
like this:

auth       optional   pam_faildelay.so  delay=3000000

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>:
Bug#531341; Package login. (Mon, 01 Jun 2009 07:24:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christian Perrier <bubulle@debian.org>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>. (Mon, 01 Jun 2009 07:24:04 GMT) Full text and rfc822 format available.

Message #15 received at 531341@bugs.debian.org (full text, mbox):

From: Christian Perrier <bubulle@debian.org>
To: Dmitri Gribenko <gribozavr@gmail.com>, 531341@bugs.debian.org
Subject: Re: [Pkg-shadow-devel] Bug#531341: prints "login incorrect" without asking for password when entering an invalid login
Date: Mon, 1 Jun 2009 09:19:15 +0200
[Message part 1 (text/plain, inline)]
Quoting Dmitri Gribenko (gribozavr@gmail.com):
> On Mon, Jun 1, 2009 at 9:14 AM, Christian Perrier <bubulle@debian.org> wrote:
> > login uses PAM for this and defaults settings are correct wrt brute
> > force attackes, with a 3 seconds delay before answering "Login incorrect".
> 
> The delay is there and works as expected.  The problem is that an
> attacker can distinguish between a valid and an invalid login (in the
> latter case password is not asked -- this is the problem).  Thus, he
> can first brute force for a login, then for a password.  If he
> couldn't, he would now know which logins are valid on the system.


(please answer to the bug report so that the whole thread remains
archived there)

Well, IIRC, this has been debated many times already, in both the
Debian package development history and during the upstream development
(the Debian maintainer, Nicolas François, is now upstream for shadow).

Again, I don't really see how one could *really* brute force logins
when PAM sets a 3 seconds delay for its answer....but let's see what
light can be pu tby Nicolas on this: his emory of these discussions is
maybe better than mine.


[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>:
Bug#531341; Package login. (Sat, 18 Jul 2009 17:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nicolas François <nicolas.francois@centraliens.net>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>. (Sat, 18 Jul 2009 17:21:05 GMT) Full text and rfc822 format available.

Message #20 received at 531341@bugs.debian.org (full text, mbox):

From: Nicolas François <nicolas.francois@centraliens.net>
To: Dmitri Gribenko <gribozavr@gmail.com>, 531341@bugs.debian.org
Subject: Re: Bug#531341: prints "login incorrect" without asking for password when entering an invalid login
Date: Sat, 18 Jul 2009 19:18:21 +0200
Hi,

On Sun, May 31, 2009 at 09:27:09PM +0300, Dmitri Gribenko wrote:
> 
> If you enter an invalid login, you get "login incorrect" immediately.
> Expected behavior is that password should be asked regardless of login
> correctness.  This is to mitigate user enumeration attacks.

Please look at the pam_securetty.so section in /etc/pam.d/login

There are two contradicting security goals which are to avoid having root's
password entered on unsafe lines (and unknown users should be considered
as a mistyped 'root'), and to avoid leaking information regarding existing
users.

I don't really know how to handle this bug. My preference would go to
close it (which I will do in a few week if there are no answers). Another
solution could be to keep it as wontfix as an "information bug" and wait
until somebody finds a cleaner solution.

Dmitri, changing the inclusion of pam_securetty.so from requisite to
required is probably what you are looking for.

Best Regards,
-- 
Nekral




Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>:
Bug#531341; Package login. (Sat, 18 Jul 2009 19:36:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitri Gribenko <gribozavr@gmail.com>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>. (Sat, 18 Jul 2009 19:36:06 GMT) Full text and rfc822 format available.

Message #25 received at 531341@bugs.debian.org (full text, mbox):

From: Dmitri Gribenko <gribozavr@gmail.com>
To: Nicolas François <nicolas.francois@centraliens.net>, 531341@bugs.debian.org
Subject: Re: Bug#531341: prints "login incorrect" without asking for password when entering an invalid login
Date: Sat, 18 Jul 2009 22:31:04 +0300
On Sat, Jul 18, 2009 at 8:18 PM, Nicolas
François<nicolas.francois@centraliens.net> wrote:
> Please look at the pam_securetty.so section in /etc/pam.d/login
>
> There are two contradicting security goals which are to avoid having root's
> password entered on unsafe lines (and unknown users should be considered
> as a mistyped 'root'), and to avoid leaking information regarding existing
> users.

Thank you for the explanation.

> I don't really know how to handle this bug. My preference would go to
> close it (which I will do in a few week if there are no answers). Another
> solution could be to keep it as wontfix as an "information bug" and wait
> until somebody finds a cleaner solution.

I think it is better to keep it as wontfix.

Best regards,
Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/




Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>:
Bug#531341; Package login. (Sun, 19 Jul 2009 08:39:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nicolas François <nicolas.francois@centraliens.net>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>. (Sun, 19 Jul 2009 08:39:07 GMT) Full text and rfc822 format available.

Message #30 received at 531341@bugs.debian.org (full text, mbox):

From: Nicolas François <nicolas.francois@centraliens.net>
To: 531341@bugs.debian.org
Subject: Re: Bug#531341: prints "login incorrect" without asking for password when entering an invalid login
Date: Sun, 19 Jul 2009 10:28:00 +0200
tags 531341 wontfix
thanks

There are two contradicting security goals which are to avoid having root's
password entered on unsafe lines (and unknown users should be considered
as a mistyped 'root'), and to avoid leaking information regarding existing
users.

The default can be changed in /etc/pam.d/login.

I'm keeping the bug open and tagged wontfix...
until another solution is found or enough arguments are provided to change
the default for Debian.

Best Regards,
-- 
Nekral




Tags added: wontfix Request was from Nicolas François <nicolas.francois@centraliens.net> to control@bugs.debian.org. (Sun, 19 Jul 2009 12:18:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>:
Bug#531341; Package login. (Mon, 20 Jul 2009 22:30:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nicolas François <nicolas.francois@centraliens.net>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>. (Mon, 20 Jul 2009 22:30:04 GMT) Full text and rfc822 format available.

Message #37 received at 531341@bugs.debian.org (full text, mbox):

From: Nicolas François <nicolas.francois@centraliens.net>
To: tallgirl@austin.rr.com
Cc: 531341@bugs.debian.org, debian-security@lists.debian.org
Subject: Re: Debian bug 531341
Date: Tue, 21 Jul 2009 00:25:10 +0200
Hello,

On Mon, Jul 20, 2009 at 02:01:27PM -0500, tallgirl@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"
 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.

I do not think those requirements can be satisfied at the same time.


The current /etc/pam.d/login contains:
auth       requisite  pam_securetty.so

The intent is that if root logs on a non secure line, the PAM stack is
interrupted immediately (changing requisite to required would just make
the login fail, but other modules in the PAM stack would be triggered),
hence the user will not be prompted for a password, hence (hopefully) the
root password will not pass through this insecure line.

Now if root mis-type her username (let say rot instead of root),
pam_securetty.so will just notice that this is an unknown username, and
will still return with an error. The stack will also be interrupted
immediately to stop root from typing her password.

The right configuration depends on the risks defined by the admin.
If the admin knows that login might be used on insecure lines, then she
might prefer to use requisite. If she knows that there are no insecure
lines, required would be sufficient (and the line could even be commented
out).

If somebody eavesdrops on an insecure line and get the root password,
she can log in immediately.
If somebody manage to find what are the valid users on the system, the
accounts should still be protected by passwords.
This was the reason why I tent to favor the requisite rather than the
required.

I asked for pam_securetty not to reject unknown users on secure ttys, but
this request was rejected (sorry, no pointers).

So, I don't think there are any sane default that will work for any
configuration (from the login point of view, it is not just a matter of
code/configuration; it is just not possible to satisfy those three
requirements; one of them need to be removed/loosened)

 1. requisite is changed to required / pam_securetty is removed
 2. Use the following instead of requisite:
 [success=ok new_authtok_reqd=ok user_unknown=ok ignore=ignore default=die]
 3. The current solution, use requisite

(A 4th solution, which would be not to return PAM_USER_UNKNOWN when the
line is secure could be better, but I do not remember why it was rejected)

Since there are no good solutions, what would be the best for Debian?


Now let's see if debian-security has some ideas on what the default should
be...

Best Regards,
-- 
Nekral




Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>:
Bug#531341; Package login. (Tue, 21 Jul 2009 04:42:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>. (Tue, 21 Jul 2009 04:42:02 GMT) Full text and rfc822 format available.

Message #42 received at 531341@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: tallgirl@austin.rr.com
Cc: 531341@bugs.debian.org
Subject: Re: Debian bug 531341
Date: Tue, 21 Jul 2009 06:37:00 +0200
Nicolas François <nicolas.francois@centraliens.net> writes:

> Hello,
>
> On Mon, Jul 20, 2009 at 02:01:27PM -0500, tallgirl@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

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.

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

> I do not think those requirements can be satisfied at the same time.

But near enough.

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>:
Bug#531341; Package login. (Tue, 21 Jul 2009 06:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Julie" <tallgirl@austin.rr.com>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>. (Tue, 21 Jul 2009 06:57:02 GMT) Full text and rfc822 format available.

Message #47 received at 531341@bugs.debian.org (full text, mbox):

From: "Julie" <tallgirl@austin.rr.com>
To: "Goswin von Brederlow" <goswin-v-b@web.de>, <531341@bugs.debian.org>
Cc: <531341@bugs.debian.org>
Subject: Re: Bug#531341: Debian bug 531341
Date: Tue, 21 Jul 2009 01:53:31 -0500
From: "Goswin von Brederlow" <goswin-v-b@web.de>
> Nicolas François <nicolas.francois@centraliens.net> writes:
>> On Mon, Jul 20, 2009 at 02:01:27PM -0500, tallgirl@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. 





Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>:
Bug#531341; Package login. (Tue, 21 Jul 2009 11:42:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>. (Tue, 21 Jul 2009 11:42:03 GMT) Full text and rfc822 format available.

Message #52 received at 531341@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: "Julie" <tallgirl@austin.rr.com>
Cc: "Goswin von Brederlow" <goswin-v-b@web.de>, <531341@bugs.debian.org>
Subject: Re: Bug#531341: Debian bug 531341
Date: Tue, 21 Jul 2009 13:35:59 +0200
"Julie" <tallgirl@austin.rr.com> writes:

> From: "Goswin von Brederlow" <goswin-v-b@web.de>
>> Nicolas François <nicolas.francois@centraliens.net> writes:
>>> On Mon, Jul 20, 2009 at 02:01:27PM -0500, tallgirl@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




Removed tag(s) wontfix. Request was from Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net> to control@bugs.debian.org. (Fri, 24 Jul 2009 01:16:03 GMT) Full text and rfc822 format available.

Added tag(s) pending. Request was from Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net> to control@bugs.debian.org. (Fri, 24 Jul 2009 01:16:04 GMT) Full text and rfc822 format available.

Reply sent to Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net>:
You have taken responsibility. (Fri, 24 Jul 2009 04:45:09 GMT) Full text and rfc822 format available.

Notification sent to Dmitri Gribenko <gribozavr@gmail.com>:
Bug acknowledged by developer. (Fri, 24 Jul 2009 04:45:10 GMT) Full text and rfc822 format available.

Message #61 received at 531341-close@bugs.debian.org (full text, mbox):

From: Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net>
To: 531341-close@bugs.debian.org
Subject: Bug#531341: fixed in shadow 1:4.1.4.2-1
Date: Fri, 24 Jul 2009 04:17:15 +0000
Source: shadow
Source-Version: 1:4.1.4.2-1

We believe that the bug you reported is fixed in the latest version of
shadow, which is due to be installed in the Debian FTP archive:

login_4.1.4.2-1_i386.deb
  to pool/main/s/shadow/login_4.1.4.2-1_i386.deb
passwd_4.1.4.2-1_i386.deb
  to pool/main/s/shadow/passwd_4.1.4.2-1_i386.deb
shadow_4.1.4.2-1.diff.gz
  to pool/main/s/shadow/shadow_4.1.4.2-1.diff.gz
shadow_4.1.4.2-1.dsc
  to pool/main/s/shadow/shadow_4.1.4.2-1.dsc
shadow_4.1.4.2.orig.tar.gz
  to pool/main/s/shadow/shadow_4.1.4.2.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 531341@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net> (supplier of updated shadow package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Fri, 24 Jul 2009 05:03:23 +0200
Source: shadow
Binary: passwd login
Architecture: source i386
Version: 1:4.1.4.2-1
Distribution: unstable
Urgency: low
Maintainer: Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>
Changed-By: Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net>
Description: 
 login      - system login tools
 passwd     - change and administer password and group data
Closes: 479406 525726 531341 531983 534244 535553 535927
Changes: 
 shadow (1:4.1.4.2-1) unstable; urgency=low
 .
   * The "Tome des Bauges" release.
   * New upstream release:
      - Updated Basque translation. Closes: #535553
      - Fixed some translatable string. Closes: #525726
      - Fixed documentation of the short option for --mindays in passwd(1).
        Closes: #531983
      - Added support for shells being shell scripts without a shebang.
        Closes: #479406
   * debian/securetty.linux: Added Embedded Renesas SuperH ports.
     Closes: #535927
   * debian/securetty.linux: Added ttyS2 to ttyS5. Some extension card provide
     more serial ports, but that should be sufficient until there is a support
     for regular expressions. Closes: #534244
   * debian/patches/506_relaxed_usernames: Fixed typo. groupadd(8) should
     document the restriction on groupnames, not usernames.
   * debian/login.pam: pam_securetty included as a required module instead of
     requisite to avoid leak of user name information. Closes: #531341
   * debian/shadowconfig.sh: Do not run shadowoff() and shadowon() in subshell.
     This also remove a dependency on bash (even though /bin/sh would have been
     sufficient). Thanks to Luk for spotting this.
   * debian/login.dirs, debian/passwd.dirs: Removed usr/share/linda/overrides.
   * debian/control: Standards-Version: bumped to 3.8.2. No changes.
Checksums-Sha1: 
 7a3a2461b39efe722b785fa622ea7cf646f3094f 1555 shadow_4.1.4.2-1.dsc
 31ddbcbe7c0eee42f2a345e10056272b547b173b 2814130 shadow_4.1.4.2.orig.tar.gz
 ff0983a540cc4f0ec2ebd7d972fa142f81c369d2 76465 shadow_4.1.4.2-1.diff.gz
 c0287aa80714c50dccaa8c5b5c2b6122653be6a5 975188 passwd_4.1.4.2-1_i386.deb
 06384a819f536a6f76643376bfd02b94c625f4be 752178 login_4.1.4.2-1_i386.deb
Checksums-Sha256: 
 217e5bc8daa11876723cb44644453d7e7e8258b060548b332a5f6516a3c5e3d5 1555 shadow_4.1.4.2-1.dsc
 17c1ab7fdce07a7d1056e436a813e18fa260aab814f0545698e9959e64cc9639 2814130 shadow_4.1.4.2.orig.tar.gz
 d49d5d7f87339dd91faf31acc5e76c8f6c7939c8b2912db15b6f98b33be836ca 76465 shadow_4.1.4.2-1.diff.gz
 afb52283c54db2e4c38358dbf77d5fd14141a65467a5a9ff3080d62978f334fc 975188 passwd_4.1.4.2-1_i386.deb
 7c99655ede7c83dec95d9a86719e5b7de96f3a6cc3d0c919d684907cc8cd798b 752178 login_4.1.4.2-1_i386.deb
Files: 
 e94e5381e3cce9600b1c77d69193a8e5 1555 admin required shadow_4.1.4.2-1.dsc
 0d9a6f7b631f3f3673c263685a0a6ab3 2814130 admin required shadow_4.1.4.2.orig.tar.gz
 0cc8efad49a9f7f36e815e703000c363 76465 admin required shadow_4.1.4.2-1.diff.gz
 2ae7b750afe852093fd38009f054b9f7 975188 admin required passwd_4.1.4.2-1_i386.deb
 4071939354328f897bfc2063c940f2a4 752178 admin required login_4.1.4.2-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkppMj4ACgkQWgo5mup89a1SmwCeJWyPNjlayPXamWeQxcnaXSXB
Jr0An1iZRQcaQe44ayUz4n+2V8XmNJu8
=a9Zd
-----END PGP SIGNATURE-----





Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>:
Bug#531341; Package login. (Wed, 02 Sep 2009 08:36:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>. (Wed, 02 Sep 2009 08:36:07 GMT) Full text and rfc822 format available.

Message #66 received at 531341@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 531341@bugs.debian.org
Subject: Re: prints "login incorrect" without asking for password when entering an invalid login
Date: Wed, 2 Sep 2009 01:32:17 -0700
[Message part 1 (text/plain, inline)]
reopen 531341
severity 531341 grave
thanks

> * debian/login.pam: pam_securetty included as a required module instead of
>     requisite to avoid leak of user name information. Closes: #531341

Please revert this change.  The 'requisite' module is necessary to prevent
exposure of the root password over insecure channels - such as telnet, but
also including unencrypted XDMCP connections.  root users should never have
the opportunity to type their password when the tty is not secure.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Bug No longer marked as fixed in versions shadow/1:4.1.4.2-1 and reopened. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 02 Sep 2009 08:36:11 GMT) Full text and rfc822 format available.

Severity set to 'grave' from 'normal' Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Wed, 02 Sep 2009 08:36:12 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>:
Bug#531341; Package login. (Tue, 16 Mar 2010 07:09:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christian PERRIER <bubulle@debian.org>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>. (Tue, 16 Mar 2010 07:09:10 GMT) Full text and rfc822 format available.

Message #75 received at 531341@bugs.debian.org (full text, mbox):

From: Christian PERRIER <bubulle@debian.org>
To: 531341@bugs.debian.org
Subject: Status of this bug
Date: Tue, 16 Mar 2010 14:03:28 +0700
[Message part 1 (text/plain, inline)]
clone 531341 -1
retitle -1 Please go back to "requisite" for pam_securetty in login.pam
severity 531341 normal
thanks

I went through the entire history of this bug report and found it
quite surprising..:-)

Nicolas very obviously supports the use of "requisite" for
pam_securetty and after his long
(http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=37;bug=531341)
explanation, there have been a few messages supporting that choice.

However, finally, /etc/pam.d/login was changed to use
"required"....which Steve Langasek immediately objected by reopening
the bug and raising its severity.

I personnally agree that we should revert that change.... I committed
this in SVN.

So, I cloned this bug to reflect Steve's intent when he reopened
it. That bug is then a "please go back to 'requisite'...." bug...and
remains RC.

On the other hand, #531341, which has never been RC gets its severity lowered.



-- 


[signature.asc (application/pgp-signature, inline)]

Bug 531341 cloned as bug 574082. Request was from Christian PERRIER <bubulle@debian.org> to control@bugs.debian.org. (Tue, 16 Mar 2010 07:09:41 GMT) Full text and rfc822 format available.

Severity set to 'normal' from 'grave' Request was from Christian PERRIER <bubulle@debian.org> to control@bugs.debian.org. (Tue, 16 Mar 2010 07:09:44 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>:
Bug#531341; Package login. (Tue, 16 Mar 2010 11:30:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nicolas François <nicolas.francois@centraliens.net>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>. (Tue, 16 Mar 2010 11:30:07 GMT) Full text and rfc822 format available.

Message #84 received at 531341@bugs.debian.org (full text, mbox):

From: Nicolas François <nicolas.francois@centraliens.net>
To: Steve Langasek <vorlon@debian.org>, 531341@bugs.debian.org
Subject: Re: Bug#531341: prints "login incorrect" without asking for password when entering an invalid login
Date: Tue, 16 Mar 2010 12:29:21 +0100
Hello Steve,

On Wed, Sep 02, 2009 at 01:32:17AM -0700, Steve Langasek wrote:
> 
> > * debian/login.pam: pam_securetty included as a required module instead of
> >     requisite to avoid leak of user name information. Closes: #531341
> 
> Please revert this change.  The 'requisite' module is necessary to prevent
> exposure of the root password over insecure channels - such as telnet, but
> also including unencrypted XDMCP connections.  root users should never have
> the opportunity to type their password when the tty is not secure.

Sorry for the long delay, and thanks to Christian for repinging on this
topic.

I would prefer to use the following (rather than a requisite):
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so

The difference with requisite is the addition of user_unknown=bad

The problem with requisite is that it leaks knowledge on the existing
usernames (with pam 1.1.0-4, this leak is limited to insecure lines, but
this might not be sufficient).

The possible user enumeration (which was very visible with pam < 1.1.0-4
since it occurred on any box on the console ttys) was the cause of
numerous complaints, so I think this default would be more sensible than a
simple "requisite".

IMHO, the only issue is that if root mis-type the username, then a
password is prompted. But I consider this can be blamed on root for:
 * mis-typing
 * not remembering that the line is insecure

Do you agree with that choice ?

Best Regards,
-- 
Nekral




Added tag(s) pending. Request was from Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net> to control@bugs.debian.org. (Thu, 18 Mar 2010 12:00:11 GMT) Full text and rfc822 format available.

Reply sent to Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net>:
You have taken responsibility. (Mon, 06 Sep 2010 08:33:12 GMT) Full text and rfc822 format available.

Notification sent to Dmitri Gribenko <gribozavr@gmail.com>:
Bug acknowledged by developer. (Mon, 06 Sep 2010 08:33:12 GMT) Full text and rfc822 format available.

Message #91 received at 531341-close@bugs.debian.org (full text, mbox):

From: Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net>
To: 531341-close@bugs.debian.org
Subject: Bug#531341: fixed in shadow 1:4.1.4.2+svn3283-1
Date: Mon, 06 Sep 2010 08:28:31 +0000
Source: shadow
Source-Version: 1:4.1.4.2+svn3283-1

We believe that the bug you reported is fixed in the latest version of
shadow, which is due to be installed in the Debian FTP archive:

login_4.1.4.2+svn3283-1_i386.deb
  to main/s/shadow/login_4.1.4.2+svn3283-1_i386.deb
passwd_4.1.4.2+svn3283-1_i386.deb
  to main/s/shadow/passwd_4.1.4.2+svn3283-1_i386.deb
shadow_4.1.4.2+svn3283-1.diff.gz
  to main/s/shadow/shadow_4.1.4.2+svn3283-1.diff.gz
shadow_4.1.4.2+svn3283-1.dsc
  to main/s/shadow/shadow_4.1.4.2+svn3283-1.dsc
shadow_4.1.4.2+svn3283.orig.tar.gz
  to main/s/shadow/shadow_4.1.4.2+svn3283.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 531341@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net> (supplier of updated shadow package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sun, 29 Aug 2010 21:14:12 +0200
Source: shadow
Binary: passwd login
Architecture: source i386
Version: 1:4.1.4.2+svn3283-1
Distribution: unstable
Urgency: low
Maintainer: Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>
Changed-By: Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net>
Description: 
 login      - system login tools
 passwd     - change and administer password and group data
Closes: 470059 530231 531341 539354 542804 544184 544523 548065 548407 554170 560633 562221 567836 569899 572687 573018 574082 576203 582166 586994
Changes: 
 shadow (1:4.1.4.2+svn3283-1) unstable; urgency=low
 .
   * The "Bleu de Gex" release.
   * New upstream unreleased version:
     - Fix formatting of the login.defs.5 manpage. Closes: #542804
     - Updated Czech translation. Closes: #548407
     - Updated Vietnamese translation. Closes: #548065
     - Remove patches applied upstream:
       + debian/patches/008_su_no_sanitize_env
       + debian/patches/483_su_fakelogin_wrong_arg0
     - Updated patches:
       + debian/patches/523_su_arguments_are_no_more_concatenated_by_default
       + debian/patches/542_useradd-O_option
     - Added support for dates already specified as a number of days since
       Epoch in useradd, usermod and chage. Closes: #562221
     - This also allows, in the chage interactive mode, to specify -1 as the
       expiration date to disable it. Closes: #573018
     - Fixed parsing of gshadow. This fix password support in newgrp.
       Closes: #569899
     - pwck and grpck stop sorting at the first line which begins with a '+'.
       This will avoid messing up with NIS entries. Closes: #567836
     - Fix interruption of su, newgrp, vipw with Ctrl-Z. Closes: 530231
     - mail checking is no more mentioned in login(1) since it is done by PAM.
       Closes: #470059
     - The -e (and -c and -m) option was restored in chpasswd (which still uses
       PAM by default).  Closes: #539354
     - Kazakh translation updated. Closes: #586994
     - Fixed comma splice in chsh(1). Closes: #582166
   * debian/securetty.kfreebsd: On GNU/kFreeBSD the serial devices have change
     from /dev/cuuaX to /dev/ttydX in kernel 6.0. Closes: #544523
   * debian/securetty.linux: Added support for embedded ARM AMBA PL011 ports
     (e.g. emulated by QEMU). Closes: #544184
   * debian/control: Removed Martin Quinson from the Uploaders, on his request.
   * debian/login.defs: Improve documentation of USERGROUPS_ENAB.
     Closes: #572687
   * debian/rules: Added DEB_AUTO_UPDATE_LIBTOOL = pre. Closes: #560633
   * debian/login.pam: return back to mostly "requisite" for the pam_securetty
     PAM module, but ignore PAM_USER_UNKNOWN. This will avoid root from
     entering a password, and will also avoid user enumeration attacks.
     Mis-typed root login are not protected, only root can be blamed for
     mis-typing and entering a password on an insecure line. Users willing to
     protect against mis-typed root login can use "requisite", but will be
     vulnerable to user enumeration attacks on insecure lines, and should use
     pam 1.1.0-4 at least. Closes: #574082, #531341
   * debian/passwd.cron.daily: Handle the backups of the user and group
     databases so that it can be removed from the standard daily cron job.
     Closes: #554170
   * debian/login.defs: Updated description of UMASK (used by pam_umask).
   * debian/securetty.linux: Reorganize and synchronize with
     Documentation/devices.txt. This added a lot of TTYs, including the
     ttyPZ0..3. Closes: #576203
   * debian/rules, debian/man.insert, debian/man.insert.sed: Hack to avoid bug
     507673, causing missing apostrophes in the manpages generated by
     docbook-xsl (see debian bug 507673).
   * debian/control: Standards-Version: bumped to 3.8.4. No changes.
   * debian/passwd.lintian-overrides: Remove old entries relevant for
     passwd.config.
   * debian/control: Do not repeat the Section and Priority fields for the
     binary packages.
   * debian/rules: Disable new features: --without-acl --without-attr
     --without-tcb
Checksums-Sha1: 
 7e6d456cac76b0edb669bc8c6b6e35988554a2aa 1574 shadow_4.1.4.2+svn3283-1.dsc
 8b704b8f07718e329205f23d457c3121c0f3679e 2942890 shadow_4.1.4.2+svn3283.orig.tar.gz
 1c59dc329cc0eb2853eef9d1704765d2802ab35a 79546 shadow_4.1.4.2+svn3283-1.diff.gz
 37078d85476f27c9fa744d790b443e326d7bad88 1033502 passwd_4.1.4.2+svn3283-1_i386.deb
 91e3b85485627e729f38a1cd5488890119f92ec8 782862 login_4.1.4.2+svn3283-1_i386.deb
Checksums-Sha256: 
 bb607350daf7f665026d3c797488cc1709760ea2db456860aa7ad5b7afcb0795 1574 shadow_4.1.4.2+svn3283-1.dsc
 2bb79a35d5610515daf6471a091025b4bf991b6c631e068baa6097a13cf83fcb 2942890 shadow_4.1.4.2+svn3283.orig.tar.gz
 0590e9eb246848abddee0a576f8d4870ab8e3b4035266e73335b171b256f5bd4 79546 shadow_4.1.4.2+svn3283-1.diff.gz
 103ad32ed5e798c3fb4c918ebe6d8c3c27fb97b10f0e812820b253f5793621e3 1033502 passwd_4.1.4.2+svn3283-1_i386.deb
 12f4501ef74528a646d85db90fb5a28a8ab91887e189d837f8bfcc603639fd12 782862 login_4.1.4.2+svn3283-1_i386.deb
Files: 
 d3e1dfa7117ea6745f686d50d09b1dac 1574 admin required shadow_4.1.4.2+svn3283-1.dsc
 10f6ddcb029c024aaf77d033bcb459d5 2942890 admin required shadow_4.1.4.2+svn3283.orig.tar.gz
 b6e34205c45409f01b1c2ab9ed2ea84e 79546 admin required shadow_4.1.4.2+svn3283-1.diff.gz
 a2a9fc8dabfffabfe425703c8b100655 1033502 admin required passwd_4.1.4.2+svn3283-1_i386.deb
 befcae284cecb4e531f3f05c04a65506 782862 admin required login_4.1.4.2+svn3283-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkyD+OcACgkQWgo5mup89a3l9gCbBlhp/AZDA7hNBjo14d/qeezh
f7AAniMTVJK+xQompzzf1Cm7Az/MaTbI
=UbtM
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 17 Oct 2010 07:33:24 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 01:19:46 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.