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

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

The problem was, quite bluntly, an incomplete understanding of PAM
mechanics on my part.

The original idea was that it was supposed to be used in conjunction
with other modules; specifically, pam_unix.  So my *thinking* (if you
could call it that) was that it would be used as such:

auth required pam_unix.so  ...
auth required pam_sshauth.so ...

Since (in my mind), accepting the root user would be handled by pam_unix,
I should simply succeed, since if the root account password was
incorrectly entered, the pam_unix result would be a FAIL, and thus
then entire pam auth stack would fail.  Therefore, in my (incorrect)
thinking,
I should simply succeed on systems accounts.

I didn't, at the time, know about the ability to skip with [success=N], or
even
consider that I would use it as the only pam module.

TL;DR: I didn't know what I was doing, and misunderstood how I should
handle systems accounts.  Mea culpa, mea maxima culpa.

Cheers,
Scott

On Tue, May 3, 2016 at 1:51 PM, Vagrant Cascadian <vagrant@...ian.org>
wrote:

> On 2016-05-03, Salvatore Bonaccorso wrote:
> > On Sun, May 01, 2016 at 10:02:15AM -0400, cve-assign@...re.org wrote:
> >> > 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>.
>
> Also bringing the primary upstream developer, Scott Balneaves
> <sbalneav@...p.org> into the conversation, who has better understanding
> of the code.
>
> For this issue, I've largely just discovered it and made some small
> effort to backport the patch.
>
>
> live well,
>   vagrant
>

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