Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 May 2016 16:57:13 +0200
From: Salvatore Bonaccorso <carnil@...ian.org>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com, Vagrant Cascadian <vagrant@...ian.org>
Subject: Re: CVE Request: libpam-sshauth: local root privilege escalation

Hi,

On Sun, May 01, 2016 at 10:02:15AM -0400, cve-assign@...re.org wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> > Due to a programming error, libpam-sshauth returned PAM_SUCCESS where
> > it should fail with PAM_AUTH_ERR. This was fixed in Debian in the last
> > upload to unstable with the attached patch.
> > 
> > https://bazaar.launchpad.net/~ltsp-upstream/ltsp/libpam-sshauth/revision/114
> 
> We can assign a CVE ID because it appears that something definitely is
> wrong from the Debian perspective, either the code itself or
> documentation/lack-of-documentation about how the code was supposed to
> be used.
> 
> Use CVE-2016-4422.

Thanks for assigning the CVE identifier.

> 
> However, we don't completely understand the issue:
> 
> > Introduced with:
> > https://bazaar.launchpad.net/~ltsp-upstream/ltsp/libpam-sshauth/revision/93/src/pam_sshauth.c
> 
> Here, the commit message for revision 93 was "Succeed for system
> accounts."
> 
> We don't know why introducing the undocumented behavior of "Is it a
> system user? Fail" would be better than simply not checking
> "pwent->pw_uid < UID_MIN" at all. Also, is there any risk that, with
> this libpam-sshauth update, a system's PAM configuration might
> suddenly provide no way for root to login via SSH?
> 
> Is it possible that the original motivation for revision 93 was that
> the PAM_SUCCESS from pam_sm_authenticate was supposed to be specially
> handled elsewhere in the "pwent->pw_uid < UID_MIN" case?
> 
> Although not directly applicable to libpam-sshauth, the examples
> section of the
> http://www.linux-pam.org/Linux-PAM-html/sag-pam_succeed_if.html man
> page shows that a set of rules is sometimes designed with UID_MIN
> special cases.

It might be right that revision 93 cannot be considred the introducing
revision for the problem. By following the example as given in the
README.

https://sources.debian.net/src/libpam-sshauth/0.3.1-1/README/#L75

$ cat /etc/pam.d/testservice 
auth    required        pam_sshauth.so host=127.0.0.1 nostrict # or wherever
auth    required        pam_exec.so expose_authtok /usr/bin/ltsp-session
session required        pam_exec.so /usr/bin/ltsp-session
$ pamtester -v testservice root authenticate open_session close_session
pamtester: invoking pam_start(testservice, root, ...)
pamtester: performing operation - authenticate
Password: <anypassword>
pamtester: successfully authenticated
pamtester: performing operation - open_session
pamtester: successfully opened a session
pamtester: performing operation - close_session
pamtester: session has successfully been closed.

I want though to add the Debian maintainer for libpam-sshauth to more
accurately answer the raised questions, Vagrant Cascadian
<vagrant@...ian.org>. 

Regards,
Salvatore

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ