Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ