Bug 871 - sudoedit doesn't drop privileges when sudoers entry has leading path
sudoedit doesn't drop privileges when sudoers entry has leading path
Status: RESOLVED FIXED
Product: Sudo
Classification: Unclassified
Component: Sudo
1.8.23
PC Linux
: normal security
Assigned To: Todd C. Miller
: 906 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-02-10 23:38 MST by bstapes.bugzilla
Modified: 2019-12-31 15:11 MST (History)
0 users

See Also:


Attachments
Patch to treat fully-qualified path to sudoedit as plain sudoedit (23.41 KB, application/octet-stream)
2019-11-05 12:37 MST, Todd C. Miller
Details

Note You need to log in before you can comment on or make changes to this bug.
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