Bug 1283635 - (CVE-2015-8239) CVE-2015-8239 sudo: Race condition when checking digests in sudoers
CVE-2015-8239 sudo: Race condition when checking digests in sudoers
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 1283636
Blocks: 1283688
  Show dependency treegraph
Reported: 2015-11-19 08:36 EST by Adam Mariš
Modified: 2016-11-08 11:20 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-01-19 08:14:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Adam Mariš 2015-11-19 08:36:46 EST
A vulnerability in functionality for adding support of SHA-2 digests along with the command was found. The sudoers plugin performs this digest verification while matching rules, and later independently calls execve() to execute the binary. This results in a race condition if the digest functionality is used as suggested (in fact, the rules are matched before the user is prompted for a password, so there is not negligible time frame to replace the binary from underneath sudo). Versions affected are since 1.8.7.

CVE assignment:

Comment 1 Adam Mariš 2015-11-19 08:37:25 EST
Created sudo tracking bugs for this issue:

Affects: fedora-all [bug 1283636]
Comment 3 Daniel Kopeček 2015-11-19 09:18:16 EST
(In reply to Adam Mariš from comment #2)
> Statement:
> Not vulnerable. This issue did not affect the versions of sudo as
> shipped with Red Hat Enterprise Linux 5, 6 and 7.

Not vulnerable in RHEL 7? What about this one:

Comment 4 Adam Mariš 2015-11-19 10:01:40 EST
Thanks, I'll update it.
Comment 5 Adam Mariš 2015-11-19 10:08:46 EST

Comment 6 Daniel Kopeček 2015-12-07 04:46:36 EST
sudo upstream updated the docs:

Comment 7 Tomas Hoger 2016-01-19 08:04:34 EST
There are now additional changes applied upstream to make sudo use fexecve where available, so the program is executed using the same file descriptor that was used to read the file for checksumming purposes.


Note that fexecve documentation explicitly notes that fexecve can only help when file to be executed is in a user writeable directory, but not when the file is also user writeable.

  The idea behind fexecve() is to allow the caller to verify (checksum) the
  contents of an executable before executing it.  Simply opening the file,
  checksumming the contents, and then doing an execve(2) would not suffice,
  since, between the two steps, the filename, or a directory prefix of the
  pathname, could have been exchanged (by, for example, modifying the target
  of a symbolic link).  fexecve() does not mitigate the problem that the
  contents of a file could be changed between the checksumming and the call
  to fexecve(); for that, the solution is to ensure that the permissions on
  the file prevent it from being modified by malicious users.
Comment 8 Tomas Hoger 2016-01-19 08:14:56 EST
This is most likely not going to get any "full" fix upstream other than documenting that it's unsafe to execute user writeable programs even if the digest check is performed.

Note You need to log in before you can comment on or make changes to this bug.