Bug 953359 - (CVE-2015-5602) VUL-1: CVE-2015-5602: sudo: Unauthorized privilege escalation in sudoedit
VUL-1: CVE-2015-5602: sudo: Unauthorized privilege escalation in sudoedit
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
Other Other
: P3 - Medium : Major
: ---
Assigned To: Kristyna Streitova
Security Team bot
maint:running:62323:important CVSSv2:...
Depends on:
  Show dependency treegraph
Reported: 2015-11-03 12:58 UTC by Sebastian Krahmer
Modified: 2019-05-01 16:42 UTC (History)
4 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Krahmer 2015-11-03 12:58:33 UTC
sudoedit fails to properly match the pathnames of edited files against
the set of allowed path's/wildchars. This allows local attackers which
are allowed to use sudoedit to replace files.



Comment 2 Sebastian Krahmer 2015-11-03 13:16:29 UTC
For SLE12, dont forget to include bsc#917806
Comment 3 Swamp Workflow Management 2015-11-03 13:25:29 UTC
An update workflow for this issue was started.
This issue was rated as important.
Please submit fixed packages until 2015-11-10.
When done, reassign the bug to security-team@suse.de.
Comment 4 Kristyna Streitova 2015-11-06 12:45:22 UTC
Upstream patches (from sudo 1.8.15):
  - http://www.sudo.ws/repos/sudo/rev/9636fd256325
  - http://www.sudo.ws/repos/sudo/rev/b8f44e834c2f

I'm trying to backport it for our sudo 1.8.10p3 now but the first patch has over 6500 rows (I sincerely hope that the most of them are just a generated code).
Comment 5 Vítězslav Čížek 2015-11-07 17:11:49 UTC
The upstream fix is insufficient.
I suggest we wait for a proper patch or write our own.

The fix just adds O_NOFOLLOW flag to open() when running sudoedit.
This only helps in the case where last component of the pathname is a symlink.
If any preceding directory component is a link, it will still be followed.
(With patched sudo)

> cd
> mkdir sudodir
> ln -s /etc/shadow sudodir/shadow
> ln -s /etc etc

> sudoedit /home/test/sudodir/shadow 
sudoedit: /home/test/sudodir/shadow: is a symbolic link  # <- symlink detected
> sudoedit /home/test/etc/shadow
sudoedit: /home/test/etc/shadow unchanged  # <- FAIL, successful open

See the discussion on upstream bugzilla:

Ultimately, it isn't a good idea to allow users to sudoedit files in directories where they have write access.
Comment 6 Sebastian Krahmer 2015-11-09 12:43:59 UTC
I'd say we wait for better solution from upstream. Are they aware of the
Comment 8 Kristyna Streitova 2015-11-09 13:18:38 UTC
(In reply to Sebastian Krahmer from comment #6)
> I'd say we wait for better solution from upstream. Are they aware of the
> shortcoming?

Yes, they are aware of the problems.
Comment 9 Vítězslav Čížek 2015-11-09 13:50:31 UTC
sudo 1.8.15 adds a new configuration option:

  If set, sudoedit will refuse to edit files located in a directory that is writable by the
  invoking user unless it is run by root.  On many systems, this option requires that the
  parent directory of the file to be edited be readable by the target user.  This flag is off by default.

Comment 10 Kristyna Streitova 2015-12-02 15:37:20 UTC
I'm afraid that there still isn't a proper patch from upstream.

As Vita said, adding O_NOFOLLOW is insufficient as it only works on the last pathname component.

Unfortunately sudoedit_checkdir option is insufficient too as it only checks if the _parent_ directory is writable. But there have to be ensured that none of the parent directories are writable by the user (i.e. the parent of the parent etc.). Moreover in that case it is hard to avoid 'time of check' vs. 'time of use' issues.

Anyway, Red Hat resolved this issue as WONTFIX:

"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."

I would suggest either to wait if the upstream comes with a proper patch or rather resolve this bug as WONTFIX, as Red Hat did, and make an appeal to users to migrate to a more secure configuration.
Comment 11 Sebastian Krahmer 2016-06-01 12:24:22 UTC
I agree to make it WONTFIX. Its very likely that (despite any patching)
one may creates a config which is vulnerable to symlink or TOCTOU
attacks. Checking/opening files as root inside user controlled
directories can never be done right. Its fare more sane to
demand a valid sudo config than to work around any possible weak config