Bug 118602 - Sudo trusts the contents of the $SHELL environment variable!!!!
Sudo trusts the contents of the $SHELL environment variable!!!!
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: sudo (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
: Security, SELinux
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-17 23:04 EST by Aleksey Nogin
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-06 21:17:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aleksey Nogin 2004-03-17 23:04:06 EST
% 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-17 23:41:32 EST
Changed it to always use "/bin/bash -c" for selinux.

sudo-1.6.7p5-21
Comment 2 Aleksey Nogin 2004-03-17 23:59:53 EST
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 08:23:17 EST
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 09:25:43 EST
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 11:21:59 EST
Is this fixed with the latest version?
Comment 6 Daniel Walsh 2004-03-24 11:25:54 EST
Yes sudo-1.6.7p5-23
policy-1.9-* I believe
Comment 7 Aleksey Nogin 2004-05-06 21:17:23 EDT
I believe this has been fixed for a while now.

Note You need to log in before you can comment on or make changes to this bug.