Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 7 Mar 2014 23:53:11 -0500 (EST)
Subject: Re: Linux-PAM pam_unix/unix_chkpwd is fail-open

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

  (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

  (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

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 ]
Version: GnuPG v1.4.14 (SunOS)


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.