[825] in linux-security and linux-alert archive
Re: [linux-security] Big security hole in kerneld's request_route
daemon@ATHENA.MIT.EDU (Mark Whitis)
Wed Jun 19 14:43:51 1996
Date: Mon, 17 Jun 1996 22:07:13 -0400 (EDT)
From: Mark Whitis <whitis@dbd.com>
To: jhenders@bogon.com
cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <E0uVPVO-0000fW-00@stdismas.bogon.com>
On Sun, 16 Jun 1996, John Henders wrote:
> Would it not be simpler to forbid linking to files that you don't have
> write permission to? Allowing this seems to me to be very little
> practical use except for use in various exploits. Is there a legitimate
> use for this?
This would be more likely to break things in the real world while still
provided far less security than the techniques I was proposing which
would only affect creation of files in selected public directories.
[Mod: Does anyone have the POSIX spec's on symlinks handy? I'm guessing
that the behavior John Henders suggested would be non-compliant as well,
but I don't have the correct publication on hand to authoritatively
verify my suspicions. --Jeff.]
There are many situations where you might want to have symbolic links
to files you only have read permission to. A few examples:
- ~/bin/ps --> /usr/ucb/ps
You have, say, a path that places system V versions first
but you want to have the ucb version of ps.
- ~/.profile --> /local/rc/default/profile
You symlink, rather than copy, the default profile to
users directories. Of course, this may confuse users,
but it lets you update the default profile and have
all uncustomized profiles automatically updated.
(There are better ways to do this...).
- ~/bin/more --> /usr/bin/less
Could also be done with an alias, unless you are in /bin/sh.
- ~/src/foo/readline --> /local/src/readline
You wish to reference one package, which you do not maintain,
from within the directory tree of another package you maintain
using relative directory names.
None of these examples are terribly compelling but my suspicion is
that it is fairly common to link to directories or files you do
not have read access to and that doing this would break many things.
Root definitely should have the ability to create symbolic links
to files which root does not have write access to (without doing
a chmod). Files owned by root (such as everyting in /bin) are often
"chmod ugo-w"'ed but should be allowed to be linked to; I shudder
to think how many frail install scripts would break if this was not
the case.
Sometimes symbolic links are frequently created before the files they link
to, also. For example, consider untarring a file which contains:
a -> b
b
Link "a" will probably be unpacked before target file "b" because
the files were probably put into the tar file in alphabetical order.
So we have about zero chance of implementing this restriction
without breaking many things.
Of course if you let a user create a symlink to a file which does
not exist YET, they may create a link to a file which they do
not have write permission when it does exist (which protects
/etc/passwd but not temporary files from this kind of attack).
A restriction that you can link to the file if it does not
exist only if you have write access to the directory the linked
object would be in would be somewhat less restrictive but
would still have many problems.
Even if you restrict creation of links to files you have write
access to, you still do not eliminate some of these security
holes we are trying to address. It protects files such
as /etc/passwd but offers no protection for files which
will be created at some point in the future in a public
directory if you can guess the names they will have. Suppose
we can guess that a program will create a temporary file
/tmp/foo
at some time in the future.
touch /tmp/foo
ln -s /tmp/foo /tmp/bar
rm /tmp/foo
Now we can exploit some priviledged program which manipulates
/tmp/bar to affect /tmp/foo. And unfortunately, some of the
security holes involving public files give you far more control
over when a file access occurs than the "find ... -exec rm {} \;"
hole such as those that involve mail.
As for the various suggestions of not putting security sensitive
files in /tmp or allowing priviledged processes to use /tmp:
- My suggestions regarding being able to selectively restrict
symbolic linking ability were not intended to be the sole
means of protection; they were intended to be used in conjuction
with other protections. The intent was to create more than
a single barrier to protect against these holes so that the
failure or ommision of one barrier would not be sufficient
to breach security.
- /stmp won't work as well as its proponents may think. It assumes
that there are only two levels of priviledge and every program
which could possibly be executed at the higher level of privilidge
must be capable of determining which level of privilidge it
is executing at and behaving accordingly. When root runs
a command it runs at a higher privledge than if an ordinary
user runs the same command. Is "uucp" priviledged or unprivilidged?
If you say uucp is priviledged than anyone who gains access to
uucp is then potentionally root. In reality, there is really
no userid or process (even "nobody") which can truly be considered
unpriviledged. Instead, there are a variety of userid's and
processes with different priviledges.
Regarding the last point, it would be better to create temporary files
within a directory structure such as:
/safetmp/userid/processid/file
With the equivalenet of
- mkdir /safetmp/userid, if it does not exist
- mkdir /safetmp/userid/processid, if it does not exist
- test if we are the owner of /tmp/userid, and /tmp/userid/processid
and abort if not.
- chmod 700 /safetmp/userid (or at least "chmod go-w")
- create/use
- delete any temporary files created
- delete the /safetmp/userid/processid directory
- DO NOT delete the /safetmp/userid directory when done
Of course you should still:
- have symlinks disabled in /safetmp
- or have symlink squashing code in your open routines, or both
- and create all /safetmp/userid directories whenever a user
is created.
A set of functions should be added to the standard library to
automatically manage tmp files. It is really silly that
programs make their own decisions about where temporary
files go anyway. Functions should be provided for
shell scripts as well for those who are unable to rid themselves
of this dangerous habit.
An option to make /tmp map to /safetmp/userid/processid automagically
would probably close a large number of security holes. It would probably
break a few things but probably nothing major and probably very little
that wasn't already in need of fixing anyway. Of course, you would
only want to map the real /tmp, not chrooted /tmp's in anonymous ftpd, etc.
---------------------------------------------------------------------------
--- Mark Whitis <whitis@dbd.com> WWW: http://www.dbd.com/~whitis/ ---
--- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 ---
---------------------------------------------------------------------------
