Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!gatech!ncar!tank!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: set-id shell scripts vs security
Message-ID: <14042@mimsy.UUCP>
Date: 18 Oct 88 09:05:55 GMT
References: <467@gould.doc.ic.ac.uk> <13958@mimsy.UUCP> <109@minya.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 24

In article <13958@mimsy.UUCP> I reminded everyone that
>>There is a large and nasty (but very friendly-looking) bug hiding behind
>>set-ID shell scripts.  The bug is embedded in the file system semantics.
>>(Actually, I do know how to fix it, even under NFS, though it is not
>>pretty, and I have never really liked set-ID scripts anyway.)

In article <109@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>This is something I've been hearing for some time, and wondering when
>the people who understand the supposed security problem are going to
>enlighten the rest of us.

We would rather refrain from shouting it out to the world.

>... I'd sure like to know what it is about the shell programming
>languages ... that make them more risky than a C program.

Nothing in particular.  The bug is in the file system semantics.  If I
say anything more explicit I feel that it will `give away the store',
as they say.  But there is nothing particularly wrong with running a
script while set to some other ID; the problem has to do with running
a script that is itself set-id.  You might call it a kernel bug.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris