Re: CVE Request: libpam-sshauth: local root privilege escalation

[cve-assign () mitre org]

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

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.

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at
  http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJXJgu2AAoJEHb/MwWLVhi2N9QP/ipqCwQfw26d7T8QCUYXXdu9
laDy1/2z/rzShOZ/nKrGNQHk/3opoik7FWDpYPDJbr367uZ8XF2I8KsiUAGAYiBb
3O3scUEvSPgUkj+5x/goeAXiLV5/q8QUg0OHigP0Gfpwv1CKAs6LAlQjt0Qaqxal
A7eghcxIrOLQPnHNEC7DEegEZy/2A+fldzfGYimgHYylznUYnNSPl5iixxH2bj0+
v51pm0dF1SQUXDjkw0TDqu2TVXOAfOcJp/tC6LVDvFLLxHldkK+MvwkG1x3jI+77
U9MbskBP2TYzswJLwkx8shQWg1KKIpbNCjUOF7/58a8uTyGo2YbX24J0jWBRNoMR
OyIrCUm3Ew7sAutg5y/13zaPwGMbKePXJDXxNrINNeASa8zlCsNdC1Q+oKXisYQw
48xPMceP2/0zuRqhBfiXqyOvRXEJWwCglOVC1dvxN1EhDN6Or5GP+alpDH9u2ynM
iLqEsYI6IJ234tJIDWCPjVGB6BngaqBZ+bOPQz0qn6sgu85WFJ++uttfAjKYaKsm
w0UZe6B/hP6dtkIvkfgi3tz61onRXUsalOXgYLdb8hKBWght7rzFgXjGzsbTFn+D
WaKFixcCZCOwSLyEStYJRlM8WNIEZuygzX6tpXaqutt6L6Wi+EqjIZwrWqeT7ZL/
1xxVfqFG6QX6ImFB4QNg
=5EIr
-----END PGP SIGNATURE-----