[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
