Xref: utzoo alt.security:1588 alt.bbs:2986 comp.unix.sysv386:551 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: It does security, eh? Ever hear of ":set shell" in vi? Message-ID: <1990Sep20.153105.28394@naitc.naitc.com> Date: 20 Sep 90 15:31:05 GMT References: <8RFgP2w163w@mudos.ann-arbor.mi.us> <2441@sud509.ed.ray.com> <1990Sep18.120450.14590@nstar.uucp> Reply-To: karl@bbs.naitc.com (Karl Denninger) Organization: A.C. Nielsen Co. Lines: 68 In article <1990Sep18.120450.14590@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: >heiser@tdw201.ed.ray.com writes: > >>What's a "public access unix" without shell access? I want to provide >>access for all of the reasons you mentioned here. If I wanted to >>continue to ONLY allow access via a menu-driven program, I'd have no >>reason to switch from my current dos bbs. > >come now - with unix (running waffle) you can spawn anything - one user >can be in wordperfect, while another in foxbase, etc. Waffle makes it >very easy to spawn applications by users - yet maintains system security. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >shell access can be risky - we have no shell access here at nstar, and >for security reasons we intend to keep it that way. 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). If not, give me the phone number, and I'll have a user shell (ie: bourne shell) in 30 seconds flat after I get "vi" up. I'll send you email from the shell account, or "write" you as sufficient evidence that I was successful. 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. There is simply no prevention available if the shell is findable on the system ANYWHERE. This means you need to "chroot" your "open" bbs, or be VERY selective about what you let your users "shell out" to. This is also a great way for people who normally have a "restricted" shell to break out of it. Editors are wonderful, aren't they? This is the reason that AKCS' installation manual specifically recommends against allowing users to use the "vi" editor if they are captive users (there's a file which lists the editors that are available to "bbs" users). The documentation also tells 'ya to make sure your other editors and packages you install as "callable" don't have this hole -- which in most cases means you need the source to same, or a high degree of confidence in the commercial package you're about to let users at. Callable system utilities are a recipe for disaster without EXTREME care in implementation or a chrooted area for the bbs in general. In general, if you want to let people at other facilities, it's best to either write your own facilities, wrappers for same with a chroot in the middle, or chroot the entire BBS system. The wrapper approach has it's own problems, as it has to run SUID root in order to do the chroot, and that's a security risk in and of itself. The only other alternative is to assign individual UNIX LEVEL accounts for all the users, and put their home directories where they can't do any harm (ie: /tmp, or a filesystem you don't care about). The first (ie: /tmp) works IF your BBS keeps all it's indices internally; if it stores them somewhere in the user's directory structure you'll get in real big trouble with this scheme (this won't work with AKCS, for example). Anyone who wants to test this theory can send me their system's phone number. If you're running external stuff you purchased, or utilities that came with the machine, and haven't taken these precautions, there's a good chance I can get a user shell in minutes. -- 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.