Bugzilla – Bug 953359
VUL-1: CVE-2015-5602: sudo: Unauthorized privilege escalation in sudoedit
Last modified: 2023-04-17 06:59:39 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. rh#1277426 References: https://bugzilla.redhat.com/show_bug.cgi?id=1277426 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-5602 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5602 Reproducer: https://www.exploit-db.com/exploits/37710/
For SLE12, dont forget to include bsc#917806
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. https://swamp.suse.de/webswamp/wf/62323
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).
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: http://bugzilla.sudo.ws/show_bug.cgi?id=707 Ultimately, it isn't a good idea to allow users to sudoedit files in directories where they have write access.
I'd say we wait for better solution from upstream. Are they aware of the shortcoming?
(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.
sudo 1.8.15 adds a new configuration option: sudoedit_checkdir 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. http://www.sudo.ws/repos/sudo/rev/f5349d059a98
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: <cite> "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." </cite> 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.
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 setting.