guyton@randvax.UUCP (Jim Guyton) (04/14/86)
I see someone has finally posted a trojan horse shar file
to net.sources (the "relink" program).
I'd been worried about "shar" format for a long time; running
random shell scripts is the next best thing to running random
binaries. I'm glad the first widely posted bogus shar file
was just an april fool's joke. It could have included a few
"rm -rf /" in there ... I wonder how many people would have
run it while root and found that the hard way?
Needed: a better (safer) method of source distribution.
--------------------------------------------------------
We've got shar, tar, cpio, and ar. None of which is very good for this
kind of thing. How about a new format that can be parsed easily by
a "trusted" program so I can extract new source distributions as root
without getting the least be nervous? All you need is ...
o some file format that is trivial to parse.
o the trusted program being short enough to be fairly foolproof.
It could simply open the input file, make a new subdir, and
"chroot" to it to protect the rest of the system from absolute
pathnames in the distribution or crazy dot-dot paths.
Anyone else interested in killing off shar, or am I the only
paranoid person on the net?
-- Jim Guytonken@turtlevax.UUCP (Ken Turkowski) (04/16/86)
In article <214@randvax.UUCP> guyton@randvax.UUCP (Jim Guyton) writes: >We've got shar, tar, cpio, and ar. None of which is very good for this >kind of thing. I thought that ar (the portable, readable archive, as used in BSD and posted on the net a while ago) was supposed to be perfect for this kind of stuff. It never really caught on, though. Anyone know why? I think is might be that shar generators are easy to hack together and personalize. -- Ken Turkowski @ CIMLINC, Menlo Park, CA UUCP: {amd,decwrl,hplabs,seismo}!turtlevax!ken ARPA: turtlevax!ken@DECWRL.DEC.COM
chris@umcp-cs.UUCP (Chris Torek) (04/17/86)
In article <1133@turtlevax.UUCP> ken@turtlevax.UUCP (Ken Turkowski) writes: >I thought that ar [...] was supposed to be perfect for [making shell >archives]. It never really caught on, though. Anyone know why? It is not perfect for such purposes: It does not handle subdirectories, nor does it protect against mailers munching `dot' lines, `From ' lines, and the like. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
grr@cbmvax.cbm.UUCP (George Robbins) (04/17/86)
In article <1133@turtlevax.UUCP> you write: >In article <214@randvax.UUCP> guyton@randvax.UUCP (Jim Guyton) writes: >>We've got shar, tar, cpio, and ar. None of which is very good for this >>kind of thing. > >I thought that ar (the portable, readable archive, as used in BSD and >posted on the net a while ago) was supposed to be perfect for this >kind of stuff. It never really caught on, though. Anyone know why? >I think is might be that shar generators are easy to hack together >and personalize. > >Ken Turkowski @CIMLINC, Menlo Park, CA {amd,decwrl,hplabs,seismo}!turtlevax!ken Shar is attractive because it doesn't require an unshar program! Just about everyone on the net has /bin/sh and the utilities frequently invoked by shar files. I believe that there is a 'safe' unshar program or script floating around the net somewhere - either in the news distribution or in mod.sources. My solution is to call the shar file up with vi, give it a quick scan, and then use the ex command :.,$w !sh to pipe the shar into the shell. Doesn't work too well on systems w/o vi though... -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
bzs@bu-cs.UUCP (04/19/86)
A thought on making un-shar'ing safer: Obviously making a chroot'd account with a private bin, usr/bin and usr/ucb (if applicable) would make this much, much safer. One could also carefully limit the commands (is there any good reason for an unshar to ever do an 'rm'? you could put 'rm' somewhere else for use within this account.) Too much trouble? Maybe, everything is a trade-off, but I suspect this is fairly fool-proof for hack's directly in shar files, obviously no help if the program thus built has more hacks (although testing it in that environment would help.) -Barry Shein, Boston University
bill@sigma.UUCP (William Swan) (04/21/86)
In article <214@randvax.UUCP> guyton@randvax.UUCP (Jim Guyton) writes: >[...] I'd been worried about "shar" format for a long time; running >random shell scripts is the next best thing to running random binaries.[...] >How about a new format that can be parsed easily by a "trusted" program [...]? >All you need is ... > o some file format that is trivial to parse. > o the trusted program being short enough to be fairly foolproof.[...] >Anyone else interested in killing off shar, or am I the only >paranoid person on the net? PLEASE DON'T KILL OFF SHAR!! It has been used so often, it is almost a de facto standard for distribution. Creating a new file format will only create a lot of confusion. Besides, the format of "shar" files is quite adequate and probably not too difficult to parse. INSTEAD... Why not write "unshar.c", which would complement the "standard" (is there one?) "shar.c". It would execute _only_ those commands, no more, no less. Surely not too difficult, hmm?
bobd@zaphod.UUCP (Bob Dalgleish) (04/21/86)
I guess that I am a little unclear why we can't make "shar" safe.
A) Never (never, never,never,never,never,never,never) unshar anything as
root!
B) For you paranoids out there (and us in here), set the path for
"unshar" to directories called /rbin and /usr/rbin. Each of them has
links to the requisite programs in /bin and /usr/bin that are required
for shar to work: sed, test, wc, echo, cat, and mkdir. Daring
people might even include mv in this list. Better yet is to have the
unshar program enforce the path.
--
[Forgive me, Father, for I have signed ...]
Bob Dalgleish ...ihnp4!{alberta!}sask!zaphod!bobd
(My mother has disclaimed any knowledge of me)roy@phri.UUCP (Roy Smith) (04/23/86)
In article <474@zaphod.UUCP> bobd@zaphod.UUCP (Bob Dalgleish) writes: > I guess that I am a little unclear why we can't make "shar" safe. As has already been pointed out, no matter how safe you make the un-shar program, you still havn't done anything about the actual code that you are going to compile and run (or the Makefile, or ...) so all you've really done is shoved your head a bit further into the sand. -- Roy Smith, {allegra,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
campbell@maynard.UUCP (Larry Campbell) (04/27/86)
> A thought on making un-shar'ing safer: > > Obviously making a chroot'd account with a private bin, usr/bin and > usr/ucb (if applicable) would make this much, much safer. One could > also carefully limit the commands (is there any good reason for an > unshar to ever do an 'rm'? you could put 'rm' somewhere else for use > within this account.) ... > -Barry Shein, Boston University This code already exists, I think... "uuhosts" comes with a program called "mapsh" that chroots to a specified directory and then execs an arbitrary program. You just need to pipe the shar archive into a "mapsh /bin/sh". All we need is to standardize on what set of programs need to be available to shar scripts (many sites don't have the disk space to have two copies of everything in /usr/bin, and you *don't* want to use links for obvious reasons). -- Larry Campbell The Boston Software Works, Inc. ARPA: maynard.UUCP:campbell@harvard.ARPA 120 Fulton Street UUCP: {harvard,cbosgd}!wjh12!maynard!campbell Boston MA 02109
levy@ttrdc.UUCP (Daniel R. Levy) (05/01/86)
In article <288@maynard.UUCP>, campbell@maynard.UUCP writes: >> Obviously making a chroot'd account with a private bin, usr/bin and >> usr/ucb (if applicable) would make this much, much safer. One could >> also carefully limit the commands (is there any good reason for an >> unshar to ever do an 'rm'? you could put 'rm' somewhere else for use >> within this account.) ... >> -Barry Shein, Boston University >This code already exists, I think... "uuhosts" comes with a program >called "mapsh" that chroots to a specified directory and then execs an >arbitrary program. You just need to pipe the shar archive into a >"mapsh /bin/sh". All we need is to standardize on what set of >programs need to be available to shar scripts (many sites don't have >the disk space to have two copies of everything in /usr/bin, and you >*don't* want to use links for obvious reasons). >Larry Campbell The Boston Software Works, Inc. >ARPA: maynard.UUCP:campbell@harvard.ARPA 120 Fulton Street >UUCP: {harvard,cbosgd}!wjh12!maynard!campbell Boston MA 02109 It's not very obvious to me (why links won't do) unless the shar archive must be run as 'root' or some other account that has the privilege to overwrite the linked executables. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy