Date: Fri, 7 Mar 2014 23:53:11 -0500 (EST) From: cve-assign@...re.org To: solar@...nwall.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: Linux-PAM pam_unix/unix_chkpwd is fail-open -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This seems to be slightly different from the usual "fail-open" concept. There would be a traditional "fail-open" if a nonexistent helper program meant that all passwords were considered valid. In any case, if we understand the threat model correctly, there is no CVE assignment for this. The situation seems to be: (1) part of the PAM software needs to run a helper program by using execve (2) the purpose of the helper program is to check whether a password is correct (3) the helper program is inherently a trusted program (it is under the same administrative control as the PAM software) (4) the helper program could use a simple programming model in which a zero exit status confirms that the password is correct, and no other exit status confirms that (5) if the helper program is correctly written, and the operating system is behaving normally, this programming model is sufficient (6) however, some people feel that this is not good enough. Specifically, they feel that the PAM software must have a defense against the possibility that the helper program has a minor logic error in which it sometimes has an unintended zero exit status. (7) there are two examples of ways to have this defense: (A) the exit status of the helper program is not used, and instead the helper program must print "authorized" or (B) the helper program must exit with the status 0x0a00ff7f, which is less likely to occur with a logic error Is (5) above inaccurate? In other words, is the threat model that the PAM software is realistically sometimes used on systems in which waitpid determines that WIFEXITED was true and WEXITSTATUS was zero, even though the actual code path of the helper program provided a nonzero exit status? Are we, for example, anticipating kernel bugs or hardware bugs that cause this? If not, then why is 0x0a00ff7f implemented only for this interprocess-communication case, and not for in-process function calls? In other words, any time that a C program calls a security-critical function and tests for a return value of zero, shouldn't this be changed to a return value of, for example, 0x0a00ff7f? Any function might have a minor logic error in which it calls "return;" or reaches the end, even though "return -1" was intended. Going back to the execve case, one downside of the Owl change is that a custom helper program designed for another distribution apparently has to be modified before it is used on Owl. In other words, maintainability is reduced a little, apparently in favor of a defense-in-depth security improvement. This is not the type of scenario that would typically have a CVE ID. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJTGp7xAAoJEKllVAevmvms+aIH/1ThcAu0CzkYUe6uxZ62lc7Z hNTCveHhOx6t4LG1RIY9IlWWAO7vfLYzsqLn0Xdw7q4JCzcmGk0T5zIFRejAF52r vEbGhTwdZD5dbZAQzECrbw2fB4MUdpIx8tmFSJmfNBBRAfEe6wJAFRJSxWpElz5/ TUk2gVrlPyVZtwGDAbRwG7iOgOlIZOxmfbx/LfgoJ7v1F29BthzNGOpcYmCHbUoK 3NBUuJBqgOsFthesEAvanMQAnB8MWxCecBiG0vyUhmdSn0gSx4JFcvqAsuDilGku bCKfhFIXddzucQCVmHKzf0R5B9QSQtANRzUCbo8hHVqENh2eBmEXvxe0VjHihrA= =ndsk -----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