Path: utzoo!utgpu!water!watmath!clyde!rutgers!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: comp.misc
Subject: Re: Trojan Horse a Myth?
Message-ID: <30800002@ccvaxa>
Date: 9 Dec 87 06:37:00 GMT
References: <459@gtx.com>
Lines: 48
Nf-ID: #R:gtx.com:459:ccvaxa:30800002:000:2585
Nf-From: ccvaxa.UUCP!aglew    Dec  9 00:37:00 1987


Break-ins to Gould's Secure UNIX:

I'm not on Secure UNIX, but I believe that this is the real story -
at a trade show, the Gould exhibit made the break-in challenge.
Normally, of course, Secure UNIX administrators do not have . in their
path, but in this case root had just finished installing a 3rd party
software package that came complete with instructions to "Put . in your
path in order to run the installation script". Sigh. The penetrator
went up to the exhibitor, and asked him to help him out... try ls'ing
this directory... Sigh.
    Now, the rules of the challenge expressly forbid Trojan Horses (since 
there's not too much the OS can do about stupid system administrators),
but the penetrator got shirty, and the Gould exhibitor was probably nervous,
so they made a ruckus about it. Eventually it got back here (we heard about
it on the USEnet) and the penetrator got his prize.

---

Enough of the company product. A 100% personal, definitely not company
policy, widely disapproved of by my co-workers, opinion: the problem is
not "." in the path.
   "." in the path is a great convenience. It lets you move around to
particular environments, and use commands special to that environment.
In fact, I have occasionally had a path that runs . ./bin ../bin ../../bin
../../../bin and so on - and it was *greatly* convenient. I would like
to have a shell that had a syntax {../}*bin, or similar - search up the
path until you get to the top.
    The trouble is not the relative pathnames - the trouble is that they
relative pathnames are not *SECURE*. I mean, if /usr/bin is writable to the
world, then not having . in his path doesn't help root at all. Nor
(a more likely occurrence) does it help if root is installing a software
package, picks up some filespace in /tmp, and starts running a long
lasting installation procedure that uses scripts pulled from where he's 
installing.
    What is needed is a security predicate that prevents root from executing
non-secure code *wherever* it might be found. This might involve, on every
invocation, checking that the path to the / is non-writable, and so on.
If you have such predicates, then relative pathnames like . and ./bin
are as secure as any other.


Andy "Krazy" Glew. Gould CSD-Urbana.    1101 E. University, Urbana, IL 61801   
aglew@mycroft.gould.com    ihnp4!uiucdcs!ccvaxa!aglew    aglew@gswd-vms.arpa
   
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.