Xref: utzoo alt.security:1616 alt.bbs:3022 comp.unix.sysv386:677
Path: utzoo!attcan!uunet!bbs!karl
From: karl@naitc.naitc.com (Karl Denninger)
Newsgroups: alt.security,alt.bbs,comp.unix.sysv386
Subject: Re: Protecting against downloads
Summary: I consider the "feature" in vi a bug; it subverts other features.
Message-ID: <1990Sep24.153529.8627@naitc.naitc.com>
Date: 24 Sep 90 15:35:29 GMT
References: <2441@sud509.ed.ray.com> <1990S <1990Sep20.153105.28394@naitc.naitc.com> <1990Sep22.024446.3305@chinet.chi.il.us>
Reply-To: karl@bbs.naitc.com (Karl Denninger)
Organization: A.C. Nielsen Co.
Lines: 40

In article <1990Sep22.024446.3305@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>In article <1990Sep20.153105.28394@naitc.naitc.com> karl@bbs.naitc.com (Karl Denninger) writes:
>
>>I hope you don't allow "vi" access, or you have the bbs in a "chroot"ed area
>>with no backlinked files (ie: no linked files between the areas).
>
>What is the danger of linked files if the users don't have write permssion
>to any of them?  It takes a non-trivial amount of baggage to make vi
>happy (at least on modern SysV it wants the shared libs, all of
>/usr/lib/terminfo/*/*, TMPDIR, plus the shell and whatever tools you
>need for paragraph reformatting, sorting and the like).  Too bad we
>don't have read-only symlinks.

Because if the user gets root in the subshell, he can then modify the "read
only" files and possibly gain access to the main system area.  The most
graphic example of this is if you are foolish enough to link /etc/passwd
(and /etc/shadow for those systems who use it) into the chrooted area.  That
is as good as not having the chroot in there at all!  Anyone who gets root
in the chrooted area now can change the password file in the MAIN system
area, and thus break in with ease.

>>Without source code to "vi" there is NO WAY to prevent this.  Believe me.  
>>I had this rather graphically illustrated to me once; it's a flaw in the
>>way vi works.
>
>Actually it's a feature of the way unix works - all the tools expect to
>be able to include all the others. 

Yeah, some feature.  It subverts the restricted shell instantly, and isn't
well documented in the "Bugs" section of the manual (I believe that any tool
which has this kind of property ought to make note of it in the manual
pages at a minimum!)  Most people are unaware of the consequences of this
"feature" and a number have gotten caught by it over the years.

--
Karl Denninger	AC Nielsen
kdenning@ksun.naitc.com
(708) 317-3285
Disclaimer:  Contents represent opinions of the author; I do not speak for
	     AC Nielsen on Usenet.