[1098] in linux-security and linux-alert archive
Re: [linux-security] BoS: Mycroftish description of bash hole. (fwd)
daemon@ATHENA.MIT.EDU (Rogier Wolff)
Tue Aug 27 17:44:55 1996
To: linux-security@tarsier.cv.nrao.edu
Date: Tue, 27 Aug 1996 11:18:43 +0200 (MET DST)
From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
Mark Whitis wrote:
>From whitis@dbd.com Tue Aug 27 11:14:16 1996
Date: Tue, 27 Aug 1996 05:02:38 -0400 (EDT)
From: Mark Whitis <whitis@dbd.com>
To: Rogier Wolff <wolff@rosie.et.tudelft.nl>
cc: juphoff@tarsier.cv.nrao.edu
Subject: Re: [linux-security] BoS: Mycroftish description of bash hole. (fwd)
In-Reply-To: <199608240639.IAA00421@cave.et.tudelft.nl>
Message-ID: <Pine.SV4.3.91.960827034123.5831G-100000@top.dbd.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 24 Aug 1996, Rogier Wolff wrote:
> Mark Whitis <whitis@dbd.com> wrote:
> >
> > On Thu, 22 Aug 1996, Paul D. Robertson wrote:
> >
> > > [REW: Huh? What fool runs his Httpd as "root"?]
> >
> > It is very common to run httpd as root. If httpd is not root, then
> > everyone who has web pages has to make their home directory world
> > executable/searchable (and possibly world readable as well) if they
> > use the normal ~/public_html convention. A way around this is to
> > create public_html directories for each user in a separate directory
> > tree which you can then even chroot httpd to (of course, this would
> > be more useful if chroot actually worked).
> >
> > I submitted patches to NCSA httpd a couple years ago to fix a problem with
> > the symbolic link code which allowed anyone who had a shell account
> > to read any file on the sytem as root (if httpd was root). I believe
> > this was fixed in apache; although they didn't use my patch, since they
> > completely rewrote the symbolic link code, I think they incorporated
> > the same functionallity. The problem was that if you had symbolic
> > links enabled (as opposed to allow_symlink_ifowner) than anyone
> > with shell could create a symbolic link ("ln -s / ~/public_html/hole") which
> > would allow any file on the system to be read as root. Unfortunately,
> > on almost any system with a significant number of users, where
> > user directories are typically on more than one disk and /home/username
> > is a symbolic link to the actual location, you had to enable symbolic
> > links for httpd to access public_html directories (whether httpd
> > ran as root or not). The fix was to modify allow_symlink_ifowner
> > to also allow symbolic links owned by root.
> >
> > ---------------------------------------------------------------------------
> > --- Mark Whitis <whitis@dbd.com> WWW: http://www.dbd.com/~whitis/ ---
> > --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 ---
> > ---------------------------------------------------------------------------
>
> Then, in my eyes, you're one of those fools.
Reread my message. This time while you are awake.
Did I advocate ANYWHERE that users run httpd as root?
I merely state that it is very common, that there are reasons
to do so, and how to achieve the same results without running
httpd as root.
[REW: Ok Granted. I personally haven't seen all that many httpd's
running as root. You seem to have seen lots of them. Maybe it is
common, maybe my (or your) sample size is much too small to make
accurate guesses?]
> If a httpd is running as "root" it is asking for trouble.
If a sendmail is running as "root" it is asking for trouble.
If a ftpd is running as "root" it is asking for trouble.
If a telnetd is running as "root" it is asking for trouble.
httpd has not, so far, had a worse history than these programs
as far as bugs are concerned (badly written cgi programs aside).
Usually, however, there is not a compelling reason to run it as root
provided you take various steps to allow the desired functionality.
- Create a separate directory tree for public pages
- inside a ftp directory tree has the advantage that
you do not have to give users shell access for
them to update web pages. i.e:
- /ftp - ftpd's directory (chroot)
- /ftp/$USER - users home directory
- /ftp/$USER/public_html - html pages
- /ftp/$USER/in.comming -> /ftp/anon/in.coming/$USER
- /ftp/$USER/out.going -> /ftp/anon/out.going/$USER
- /ftp/$USER/pub -> /ftp/anon/pub/$USER
- /ftp/anon - root for anonymous ftp (chroot again)
- /ftp/anon/in.coming/$USER
- /ftp/anon/pub/$USER
- /ftp/anon/out.going/$USER
- Automatically create a symbolic link from ~/public_html
to /ftp/users/$USER/, or wherever,
- Run a separate httpd as a different non-priveledged user for cgi
applications that need restricted access to data or use a
read-only setgid cgi program (carefull!!!).
Incidently, I advocated not running httpd as root years ago
when most sites were running it as root.
Is there actually any compelling reason to run sendmail as root?
- Access to mailboxes?
chgrp mail /var/spool/mail/*
chmod g+rw /var/spool/mail/*
chgrp/chmod files listed in /etc/aliases
- Access to .forward files?
chgrp mail /home/*/.forward
- Access to mail queues
chgrp mail /var/spool/mqueue
- program mailers
these do need an external program which is setuid root
in order to chmod to the appropriate user.
I haven't really thought it through but it seems that
a slightly patched sendmail could be run as a semi-privaledged
user/group instead of root if you were willing to do a little extra
administrative work and deal with the hassle of .forward files
needing to belong to a group the user is not a member of (i.e.
you need a safe (symlink exploit proof) utility to set the permissions
or initialize .forward to "\user" and don't let users delete them
by symlinking them to a directory they don't have access to).
> Having httpd run as some "nobody" will restrict damage to what normal
> users on your system could already do. This closes "becoming root" holes
> on your system, as well as interesting ways to penetrate your system.
>
> symbolic links are usually ALWAYS owned by root. The permission and
Users also create their own symbolic links. Sometimes even within
their public_html directories:
ln -s home.html index.html
ln -s newdirectory/newfile.html oldfile.html
ln -s / security_hole
They just shouldn't be able to do the last one.
[REW: What I was saying is that even if a user actually creates a
symlink, the symlink will still be owned by root (according to the
system.....]
Symbolic links which are owned by root on file systems that are
not user mountable are generally safe.
---------------------------------------------------------------------------
--- Mark Whitis <whitis@dbd.com> WWW: http://www.dbd.com/~whitis/ ---
--- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 ---
---------------------------------------------------------------------------
