Xref: utzoo comp.unix.xenix:10221 comp.unix.i386:3078
Path: utzoo!attcan!uunet!jarthur!usc!ucsd!rutgers!mcdchg!ddsw1!karl
From: karl@ddsw1.MCS.COM (Karl Denninger)
Newsgroups: comp.unix.xenix,comp.unix.i386
Subject: Re: Using UUCP under a BBS system???
Summary: Security by obscurity is no security at all
Message-ID: <1990Feb20.202554.19826@ddsw1.MCS.COM>
Date: 20 Feb 90 20:25:54 GMT
References: <2959@murtoa.cs.mu.oz.au> <511182@nstar.UUCP> <237@elrond.locus.com> <1990Feb13.214855.4265@ddsw1.MCS.COM> <.OV1S=Axds13@ficc.uu.net>
Reply-To: karl@mcs.MCS.COM (Karl Denninger)
Organization: Macro Computer Solutions, Inc. - Mundelein, IL
Lines: 46

In article <.OV1S=Axds13@ficc.uu.net> morrison@ficc.uu.net (Brad Morrison) writes:
>In article <1990Feb13.214855.4265@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes:
>
>>The second is the killer.  Let's say you don't want people getting to the
>>shell, for whatever reason.  Here's a partial list of what you can't let
>>them execute (even internally as a pager or mailer):
>>	vi and friends (ex, view, etc)
>>	more
>>	mail
>>	pg
>>	most other editors
>>	anything with a shell escape, or anything which can chain to an editor
>
>>Why?  Well, you'd think that "SHELL=/bin/true;export SHELL" would protect
>>you from the vi ":!".  It won't.  Try ":set shell ...." sometime inside vi,
>>then a ":!...." and you'll be suitably shocked.
>
>>The same problem exists with "more"; it can chain to "vi", and from there....
>
>>There is no way to protect from this without source code to those utilities.
>>Even if you "rsh" people they can screw you using this method.  Every scheme 
>>we've tried (other than removing the shell from the system!) I've been able 
>>to penetrate within a few minutes; "rsh" environments included.  Only a
>>"chroot" environment provides reasonable safety.
>
>What about having a wrapper around the real shells that only execs the
>real one if the user id is below some threshold?  Then give your restricted
>users IDs above the threshold.

But what if the user finds out the real shell's name?

SUID'ing the "wrapper" program won't work either, since it has to set the
user id's to the real ones >before< it execs the real shell, and thus you
again can get caught out.

Security by obscurity is not security; it's hiding things.  And hidden
things aren't locked, they're simply hidden.  Of course, since they are only
hidden, they can also be found.

Once a user finds out what you called /bin/sh (if you rename it) they can
have a jolly good time using the same method as above.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910]
Macro Computer Solutions, Inc.		"Quality Solutions at a Fair Price"