headers
Nicolas François | 14 Jun 2008 22:47
Picon

pam_securetty failure for unknown users on secure ttys

Hello,

On Debian, login uses pam_securetty as a requisite module.
The reason for this is to fail immediately if the tty is not secure to
avoid prompting for a password on an insecure line.

In Linux-PAM-0_99_1_0 (pam_securetty.c revision 1.8), the return value of
the authentication function was changed from PAM_IGNORE to
PAM_USER_UNKNOWN.
When pam_securetty is a requisite module, this means that the
authentication will fail immediately if the user does not exist in the
system. This might indicate to an attacker that the given user does not
exist.

What was the rational for changing the return value from PAM_IGNORE to
PAM_USER_UNKNOWN?
(BTW the pam_securetty's manpage needs an update)

I would prefer that pam_securetty fails only if the tty is not secure and
the user is root or unknown.
And to leave the user authentication / check for validity to the pam_unix
module.

Best Regards,
--

-- 
Nekral
Permalink | Reply |
headers
Thorsten Kukuk | 15 Jun 2008 10:18
Picon

Re: pam_securetty failure for unknown users on secure ttys

On Sat, Jun 14, Nicolas François wrote:

> Hello,
> 
> On Debian, login uses pam_securetty as a requisite module.
> The reason for this is to fail immediately if the tty is not secure to
> avoid prompting for a password on an insecure line.
> 
> In Linux-PAM-0_99_1_0 (pam_securetty.c revision 1.8), the return value of
> the authentication function was changed from PAM_IGNORE to
> PAM_USER_UNKNOWN.
> When pam_securetty is a requisite module, this means that the
> authentication will fail immediately if the user does not exist in the
> system. This might indicate to an attacker that the given user does not
> exist.

If you don't like that, you can overwrite in this case (see pam.conf manual
page).

> What was the rational for changing the return value from PAM_IGNORE to
> PAM_USER_UNKNOWN?

Assume root mistypes his account name, pam_securetty would return
PAM_IGNORE, next module would allow root to correct the user name
and root is able to login on a insecure tty.

> (BTW the pam_securetty's manpage needs an update)

Please make a bug report on sf.net for this, so it does not go lost.
(Continue reading)

Permalink | Reply |
headers
Nicolas François | 15 Jun 2008 19:53
Picon

Re: [Pkg-shadow-devel] pam_securetty failure for unknown users on secure ttys

Hello,

On Sun, Jun 15, 2008 at 10:18:23AM +0200, kukuk <at> suse.de wrote:
> On Sat, Jun 14, Nicolas François wrote:
> 
> > What was the rational for changing the return value from PAM_IGNORE to
> > PAM_USER_UNKNOWN?
> 
> Assume root mistypes his account name, pam_securetty would return
> PAM_IGNORE, next module would allow root to correct the user name
> and root is able to login on a insecure tty.

I agree that unknown users should be considered as root.
But on a secure tty, root is allowed to proceed and provide her
authentication token.
On a secure tty, an unknown user should also be allowed, as root, to
provide an authentication token (which will be rejected by other modules).

On an insecure tty, an unknown user should of course be considered as
root, and be denied.

> > (BTW the pam_securetty's manpage needs an update)
> 
> Please make a bug report on sf.net for this, so it does not go lost.

Done.

> > I would prefer that pam_securetty fails only if the tty is not secure and
> > the user is root or unknown.
>
(Continue reading)

Permalink | Reply |
headers
Nicolas François | 21 Jun 2008 00:53
Picon

Re: [Pkg-shadow-devel] pam_securetty failure for unknown users on secure ttys

Hello Thorsten,

Do you think unknown users should be denied by pam_securetty on secure
TTYs?
(whether its a mistyped regular user, a mistyped root user, or a non
existing user).

On debian, login does not enforce any PAM delay (the reason was to let the
configuration of delays to PAM (instead of PAM + login.defs), and also
because delays are used to avoid brute force attack - and modules like
pam_securetty or pam_nologin do not need to be protected against brute
force attacks and can lead to an immediate failure)

With the current pam_securetty failures on secure TTYs, it is possible to
brute force usernames via login.

If the failure were limited to non-secure TTYs, this would limit the
probability of such brute force.

Best Regards,
--

-- 
Nekral
Permalink | Reply |
headers
Thorsten Kukuk | 21 Jun 2008 09:14
Picon

Re: [Pkg-shadow-devel] pam_securetty failure for unknown users on secure ttys


Hi,

On Sat, Jun 21, Nicolas François wrote:

> Hello Thorsten,
> 
> Do you think unknown users should be denied by pam_securetty on secure
> TTYs?
> (whether its a mistyped regular user, a mistyped root user, or a non
> existing user).

I think giving access if I know that something cannot be correct would
be a mistake.
On the other hand, giving access if something comes from a secure TTY
should not lead to a security problem later.

> On debian, login does not enforce any PAM delay (the reason was to let the
> configuration of delays to PAM (instead of PAM + login.defs), and also
> because delays are used to avoid brute force attack - and modules like
> pam_securetty or pam_nologin do not need to be protected against brute
> force attacks and can lead to an immediate failure)
> 
> With the current pam_securetty failures on secure TTYs, it is possible to
> brute force usernames via login.
>
> If the failure were limited to non-secure TTYs, this would limit the
> probability of such brute force.

But wouldn't a hacker come from a non-secure TTY most of the time?
(Continue reading)

Permalink | Reply |
headers
Nicolas François | 22 Jun 2008 22:50
Picon

Re: pam_securetty failure for unknown users on secure ttys

Hi,

On Sat, Jun 21, 2008 at 09:14:27AM +0200, kukuk <at> suse.de wrote:
> 
> On Sat, Jun 21, Nicolas François wrote:
> 
> > If the failure were limited to non-secure TTYs, this would limit the
> > probability of such brute force.
> 
> But wouldn't a hacker come from a non-secure TTY most of the time?
> And there you would still have the same problem with your suggestion.
> It only helps for the local console, not for network attacks.

Yes. It's far from perfect.
Enforcing a delay in login might be better to protect against brute force
attacks.

> Between, what I use to avoid your problem in /etc/pam.d/login:
> 
> auth     requisite      pam_nologin.so
> auth     [user_unknown=ignore success=ok ignore=ignore auth_err=die default=bad]        pam_securetty.so
> auth     include        common-auth

Thanks, that's what I will consider.

Best Regards,
--

-- 
Nekral
Permalink | Reply |

Gmane