Bug 871

Summary: sudoedit doesn't drop privileges when sudoers entry has leading path
Product: Sudo Reporter: bstapes.bugzilla
Component: SudoAssignee: Todd C. Miller <Todd.Miller>
Status: RESOLVED FIXED    
Severity: security    
Priority: normal    
Version: 1.8.23   
Hardware: PC   
OS: Linux   
Attachments: Patch to treat fully-qualified path to sudoedit as plain sudoedit

Description bstapes.bugzilla 2019-02-10 23:38:08 MST
Sudo version: 1.8.23
Platform: CentOS 7.6.1810

The sudoedit feature allows users to invoke an editor to edit a file, but prevents users from using features in the editor to run arbitrary commands as root. It does this by dropping privileges back to that of the invoking user.

When the sudoers entry looks like so, the feature works fine:
operator ALL = sudoedit /etc/printcap

If, however, the sudoers entry contains a leading path, sudoedit works, but privileges are not dropped. Example:
operator ALL = /bin/sudoedit /etc/printcap

Note that several distros include symlinks to sudoedit at:
/bin/sudoedit
/usr/bin/sudoedit

The second example permits arbitrary code execution as root via the vi feature to invoke shell commands from the editor. Other editors have similar features. To reproduce, enter ":!id" from vi and note that the id command executed as root.

Yes, I am aware that the documentation [1] explicitly states that sudoedit "must be specified in the sudoers file without a leading path."

Even though this is noted in the documentation, users do still use the insecure option because they're accustomed to specifying the absolute path to commands. With the symlinks in place and the fact that nothing noticeable breaks, users who are attempting to enable safe file editing accidentally open themselves to full privilege escalation as root. 

Here are some examples from Github [2][3].

This line [4] appears to be the offending line and could be modified to support the leading path. Alternatively, it could be considered invalid syntax in the sudoers file to include a leading path on sudoedit.

Please let me know if you need any other information.


[1] https://www.sudo.ws/man/1.8.23/sudoers.man.html
[2] https://github.com/thavone/dt-prod/blob/d7966c8e7818e0797b0c6df871160736cd3132ef/usr/local/etc/sudoers_sapdr#L84
[3] https://github.com/amplify-education/asiaq/blob/2cf5b6238165bc4e33b913d950f865959b69717d/sample_configuration/discoroot/etc/sudoers#L81
[4] https://github.com/millert/sudo/blob/master/src/parse_args.c#L264
Comment 1 Todd C. Miller 2019-11-05 12:30:13 MST
*** Bug 906 has been marked as a duplicate of this bug. ***
Comment 2 Todd C. Miller 2019-11-05 12:37:01 MST
Created attachment 534 [details]
Patch to treat fully-qualified path to sudoedit as plain sudoedit

In the past I've treated this as simple user error but the problem is clearly not going away on its own.

I think there are three things to be done here:

1) If the user runs "sudo sudoedit" sudo should treat it as just "sudoedit"

2) If the admin specifies a fully-qualified path for sudoedit in sudoers, sudo should treat it as just "sudoedit" and carry on

3) In visudo (but not sudo), #2 above should be treated as an error
Comment 3 bstapes.bugzilla 2019-11-05 23:29:31 MST
Thank you!
Comment 4 Todd C. Miller 2019-12-31 15:11:00 MST
Fixed in sudo 1.8.30