Date: Sun, 1 May 2016 10:02:15 -0400 (EDT) From: cve-assign@...re.org To: carnil@...ian.org Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE Request: libpam-sshauth: local root privilege escalation -----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-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ