[817] in linux-security and linux-alert archive
Re: [linux-security] Talk security?
daemon@ATHENA.MIT.EDU (Zefram)
Mon Jun 17 10:11:21 1996
From: Zefram <A.Main@dcs.warwick.ac.uk>
To: jrd@Max.stark.k12.oh.us
Date: Mon, 17 Jun 1996 00:22:28 +0100 (BST)
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <XFMail.960612220246.jrd@Max.stark.k12.oh.us> from "Justin Dobbs" at Jun 12, 96 10:00:31 pm
-----BEGIN PGP SIGNED MESSAGE-----
>Are there any security holes associated with making the talk
>program the shell of a potentially public account? The
>shell would be /usr/bin/talk <user>, with /usr/bin/talk
>listed in the /etc/shells file. Is there a potential for
>environment-style breakins?
Certainly. I wouldn't take the risk, myself -- there are several
possible avenues of attack. I think this question illustrates some
fundamental security issues, so I'll talk in general terms here.
Whatever program you use as the login shell of a restricted account
must fulfill certain criteria. It will execute in an environment (in
the broad sense of the word) over which potentially malicious people
have some control. The program must not perform any action the
administrator does not want these potentially malicious people to be
able to perform. To put it more bluntly, this program is more
privileged than the user -- it has the capability, from the OS's point
of view, to do things that the user should not be allowed to do. In
this way, the program is in a similar position to being setuid, and a
lot of the practical issues are the same.
Allow me to contrast this with the majority of programs. Most programs
have no special privilege, and the limits on their actions --
conceptually equal to the limits on whoever is running them -- are
enforced by the OS in the normal way. Privileged programs must be
written very carefully, because the OS will allow them to do more than
their invoker is allowed to do.
Given that the program in question is to be privileged, the fact that
*it was never intended to be secure* is a serious problem. When a
program is put into this privileged position, you must examine its
source, line by line, to make sure it cannot do anything other than
what it was intended to do. A simple garbaged pointer bug could allow
the program to leak privileges. And make absolutely sure that what it
does is exactly what you *want* it to do -- an undocumented feature
might, cleanly and intentionally, invoke a shell, for example.
It is always easier to make a program secure in this sense when one is
writing it from scratch, with the intention that it be privileged, than
when one is faced with an existing program that does what one wants to
do in a privileged position. I must say that, if faced with this
particular problem, I would rather rewrite the program from scratch
than review the existing code.
To take the classic example of this type of problem, /bin/{true,false}
on many systems are shell scripts, and are also used as login shells to
lock accounts. Being shell scripts is not a problem when the programs
are unprivileged (though it's inefficient and in rare cases can cause
them to misbehave), but when put in a privileged situation they give
away that privilege all too easily. I've taken advantage of this
security hole on one system, su-ing to a restricted account whose login
shell was a shell script. (That particular shell script has now been
replaced by a binary.) On *my* box, true and false are binaries -- less
than 100 bytes each (Linux a.out) -- and *completely* ignore the
environment they are run in.
On a separate issue, you mentioned putting this program into
/etc/shells. This is a very bad idea, for a number of reasons.
Basically, /etc/shells is a list of programs used as shells for
*unrestricted* accounts, and should *never* contain any program you
intend to use as the shell of a restricted account. /etc/shells is
used by several programs as a way to determine whether an account is
restricted or not -- this is a nice engineering compromise, typical of
Unix -- and adding the shell of a restricted account to it will result
in these programs giving the restricted account more access than
intended. I have seen systems that misused /etc/shells in this way,
and I've even taken advantage of the resulting security holes to a
small extent.
The most obvious thing /etc/shells is used for is nonymous ftp. You
probably don't want to allow ftp access to this account. If you do,
things get a lot more complicated. But don't forget that it's used by
other programs too; for example, GNU su (a security hole in itself, for
obvious reasons) allows the user to run an arbitrary program instead of
the target user's login shell, if the target user is an unrestricted
account (login shell in /etc/shells).
So, to summarise, *don't* put an insecure program in a privileged
position, and *don't* list a restricted shell as unrestricted.
-zefram
-----BEGIN PGP SIGNATURE-----
Version: 2.6.i
iQCVAgUBMcSXBHD/+HJTpU/hAQGe5QQApcYGEE9L76oKaER3lkQZgCLO9suC/7KO
Z+f+SjqPGF43qzLuzQ2P4CrNAIO6O3M5g50glShgCiNk7UgVl8VyfHVQDaD9AtU3
0CizdH1oV254DUgRxcVGKpf8DWvCOvqB9G8YLiQazBv8SX+25Gv6ir+Jrb6whPkY
wZQHYPfYJNA=
=1AJp
-----END PGP SIGNATURE-----
--
Andrew Main <zefram@dcs.warwick.ac.uk>
