Bug 1277426 - (CVE-2015-5602) CVE-2015-5602 sudo: Unauthorized privilege escalation in sudoedit
CVE-2015-5602 sudo: Unauthorized privilege escalation in sudoedit
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 1277427
Blocks: 1277428
  Show dependency treegraph
Reported: 2015-11-03 05:05 EST by Adam Mariš
Modified: 2016-01-19 07:53 EST (History)
10 users (show)

See Also:
Fixed In Version: sudo 1.8.15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-11 10:07:12 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-03 05:05:42 EST
An unauthorized privilege escalation was found in sudoedit when a user is granted with root access to modify a particular file that could be located in a subset of directories. It seems that sudoedit does not check the full path if a wildcard is used twice (e.g. /home/*/*/file.txt), allowing a malicious user to replace the file.txt real file with a symbolic link to a different location (e.g. /etc/shadow), which results into unauthorized access. Affected versions are <= 1.8.14.

Reproducer can be found here:

Comment 1 Adam Mariš 2015-11-03 05:06:13 EST
Created sudo tracking bugs for this issue:

Affects: fedora-all [bug 1277427]
Comment 2 Adam Mariš 2015-11-05 11:15:01 EST
Upstream patch:

Comment 3 Fedora Update System 2015-11-08 01:50:56 EST
sudo-1.8.15-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 4 Fedora Update System 2015-11-08 04:48:45 EST
sudo-1.8.15-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Comment 5 Stefan Cornelius 2015-11-11 10:05:50 EST
Configurations like the one mentioned in comment #0, where a user has edit or execute privileges for files in a directory writeable by the user, are inherently dangerous.

It's (almost?) impossible to make such scenarios entirely secure and controllable. Even with the upstream patch, which disables following symlinks by default, there is no full protection.

I can only recommend to migrate to a more secure configuration.
Comment 7 Tomas Hoger 2016-01-19 07:53:31 EST
Upstream bug report for this issue:


It notes that the fix in 1.8.15 does not completely address the issue.  Following additional changes were applied post 1.8.16:


And also related:


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