Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Sep 2000 16:54:41 +0200 (MET DST)
From:      "Vladimir Mencl, MK, susSED" <mencl@nenya.ms.mff.cuni.cz>
To:        mike.sellenschuetter@bankofamerica.com
Cc:        security@freebsd.org
Subject:   Re: UNIX locale format string vulnerability (fwd)
Message-ID:  <Pine.GSO.4.10.10009071642410.25945-100000@nenya.ms.mff.cuni.cz>
In-Reply-To: <86256953.004E2938.00@dalnsd40.bankofamerica.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Sep 2000 mike.sellenschuetter@bankofamerica.com wrote:

> Hi,
> 
> I am a learning FreeBSD systems administrator so my knowledge level of Unix is
> not at your level.  However, I have installed Sudo on the system that I
> maintain, and I don't fully understand your concern.  I agree that Sudo is a
> nice tool.  And although one can configure Sudo to prevent users assigned to a
> particular Sudo group from executing certain commands, it is my understanding
> that when a user executes a command with Sudo, his or her real and effective UID
> and GID becomes zero or root for that command.  This behavior alone creates many
> concerns because a user can exploit this to gain root access.
> 
> Within the sudoers file, I prevent a user from spawning another shell with Sudo;
> however, I can not monitor everyone's home directory for programs that when
> executed with Sudo will spawn another shell as root.  While that shell is
> active, this user owns my system, and I have to assume a certain level of trust
> with the users that I have given Sudo privileges.  It seems to me with my
> limited knowledge that the below concern is minimal compared to the other
> avenues available to users who have Sudo privileges.
> 
> Am I missing something?  This is probably the case so can you help me to
> understand your concern?

In a situation like this (when you give "nearly-the-root-shell" to the
users), and your relation with the users is based on trust, this issue
is not to be concerned.

What I was concerned about is, when only some very limited commands are
accessible via sudo, that these commands might be used to exploit the
locale vulnerability.

I'm myself using sudo only to run the "/sbin/mount /cdrom" command (and
umount).

The mount and umount commands do not use any locales, seems to me,
however other commands might.

As an example, I used the /bin/ls command - imagine, that I wish to
allow some users to list an inaccessible directory, and I decide to use
sudo for this operation.

If I add the "ALL ALL = NOPASSWD: /bin/ls -l /root/.ssh" line to the
sudoers file (just to allow anybody to check the root's .ssh directory -
a silly example, but I cannot find out any better now), /bin/ls can be
exploited.

If a malicious user types

export PATH_LOCALE=/tmp/my_evil_locales/
export LC_ALL=en_evil_locale

sudo /bin/ls -l /root/.ssh

this user might possibly cause ls to execute code forged in the evil
locale. The point is, that this would not work for setuid binaries on
FreeBSD, because setuid binaries ignore the locale settings on FreeBSD.

However, the authors of the sudo program were not aware of the dangeour
the locale environment variables present, and are passing these settings
to the programs executed. The settings should be blocked the same way
LD_* variables are blocked. 

LD_* variables are ignored by a setuid program, because this program is
aware of its setuid-ness. However, sudo, which masks the setuidness, has
to protect the programs from these variables, and should do the same for
locale setting environment variables.


Can anybody comment, whether there are any other environment variables
harmful to setuid programs (and ignored by them), which should be
blocked by sudo too, besides the LD_* and LC_* ?

And what's the status of other sudo-like ports - the su2 and super ?



			Vladimir Mencl



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10009071642410.25945-100000>