[net.sources.d] Beware of Blindly Un-SHARing a File

larry@kitty.UUCP (Larry Lippman) (04/09/86)

	Recently an article <2407@prls.UUCP> purporting to be source for a
program to ``relink'' a deleted (!) file was posted to the net as an April
Fool's joke.
	Part of the joke was funny, and part of it was not so funny.  Anyone
naive enough to believe that a deleted file could be recovered was well fooled
by the introductory remarks and the phony manual page.  The voluminous amount
of C source also gave some "credence" to the joke.  This was the funny part.
	The not-so-funny part was that the poster of the article didn't stop
at the above, but decided to play some file manipulation games.  While the
shar source would not destroy anything, this was a nasty thing to do, and the
poster showed decided lack of good taste.
	There is a valuable lesson to be learned here: NEVER, EVER blindly
unshar ANYTHING unknown!  After all, the shar source COULD have contained
something like ``rm -fr''.  That would not at all be funny.  The recent
discussions here concerning article forgery certainly illustrate how such
a shar Trojan Horse could be planted "anonymously".
	I have utilized many source postings from the Net in shar format,
but have ALWAYS examined the ENTIRE shar file for ``funny business'' using
an editor before executing it.  This really doesn't take very long to do,
since the file has to be edited to strip the header anyhow.
	I wish I had a dollar for everyone on the Net who were "fooled" by
this posting, although damn few people will admit it.  In case anyone was
wondering, I was not fooled, since I learned The Hard Way a long time ago
that "rm Means Forever"...

==>  Larry Lippman @ Recognition Research Corp., Clarence, New York
==>  UUCP    {decvax|dual|rocksanne|rocksvax|watmath}!sunybcs!kitty!larry
==>  VOICE   716/688-1231                {rice|shell}!baylor!/
==>  FAX     716/741-9635 {G1, G2, G3 modes}    duke!ethos!/
==>                                               seismo!/
==>  "Have you hugged your cat today?"           ihnp4!/

dupuy@garfield.columbia.edu (Alex Dupuy) (04/10/86)

In article <947@kitty.UUCP> larry@kitty.UUCP (Larry Lippman) writes:
>	Recently an article <2407@prls.UUCP> purporting to be source for a
>program to ``relink'' a deleted (!) file was posted to the net as an April
>Fool's joke.
>	.
>	.
>	.
>	The not-so-funny part was that the poster of the article didn't stop
>at the above, but decided to play some file manipulation games.  While the
>shar source would not destroy anything, this was a nasty thing to do, and the
>poster showed decided lack of good taste.
>	There is a valuable lesson to be learned here: NEVER, EVER blindly
>unshar ANYTHING unknown!  After all, the shar source COULD have contained
>something like ``rm -fr''.  That would not at all be funny.  The recent
>discussions here concerning article forgery certainly illustrate how such
>a shar Trojan Horse could be planted "anonymously".

    The implications of this are pretty scary; I'm sure that there are systems
out there where superusers (!) unshar files (I was guilty of this a few times).
Even more frightening than nasty pranks like rearranging directories is the
possibility of viruses.  Unix, as a more or less standard system which runs on
a wide range of computers, is especially vulnerable to viruses.

    The same laws which govern the behavior of viruses in the biological world
apply here: it is difficult for a virus to replicate in a wide variety of
hosts, but most Unix systems share a great number of characteristics and
features, with only two major population subgroups; bsd and sysv.  The emphasis
on telephone networking in Unix, due largely to its origin at Bell Labs, also
works against it, encouraging communication on an largely insecure medium.

    So what can be done?  One important step was the creation of a moderated
sources group.  While I would never install a suid root program I got from
net.sources unless I was familiar with the author by reputation, I would
probably trust John P. Nelson's judgement on the "sterility" of a program in
mod.sources.  But even non-suid programs may eventually be run by root.  This,
more than the decreasing S/N ratio of net.sources, is a powerful argument for
the total elimination (flame me, make my day :~) of net.sources.

    Another thing which can be done in the short term is to unshar programs
with something other than sh.  Last year someone posted an "unshar" program
which automatically stripped headers and signatures, and would optionally save
them in a file or unshar everything in another directory.  Alas, I misplaced
the sources (I only have Vax binaries).  So maybe the person who posted that
would send it to me, and I will add security features and repost it.  I have
some ideas on making it secure, including running suid to some innocuous user,
limiting the programs which will be exec'd to cat, sed, wc, chmod, or uudecode,
and always running in an empty subdirectory.  If anyone has other ideas, I'd be
glad to hear them.

    The threat of viruses is often overdramatized and exaggerated; I certainly
don't want to suggest that the only reasonable action is to shut down netnews
and switch to some "safe" OS like VMS, but the danger *does* exist, and I am
willing to bet a free swine flu shot (:-) that the first widespread outbreak of
a computer virus (if it ever happens) is on Unix systems of some variety.

@alex

(dupuy@columbia.edu, seismo!columbia!dupuy)

bzs@bu-cs.UUCP (Barry Shein) (04/13/86)

Although most of his points are well-taken, I would just like to niggle
a little...

>From: dupuy@garfield.columbia.edu (Alex Dupuy)
>...Unix, as a more or less standard system which runs on
>a wide range of computers, is especially vulnerable to viruses.

I don't understand this, because it ports to different chips it is
more vulnerable? Or because it runs on more machines (that's not
true, that would probably make MVS the most vulnerable)? Or because
more people know how to use it (security by obscurity, the converse,
doesn't work very well either.)?

>...[possible computer virus programs] is a powerful argument for
>the total elimination (flame me, make my day :~) of net.sources.

I don't think so, hopefully the widespread dissemination of such a
program would cause people to notice it and warn each other. I agree
this is less than perfect but I don't think trying to eliminate a
net.sources helps either. It would probably only cause people to
start sending each other programs by mail. I do agree however that
mod.sources is probably a little safer but I wouldn't *expect* the
moderator to verify and eliminate subtle viruses/trojan-horses, maybe
just perhaps blatant ones obvious by just trying the software.

>...I certainly
>don't want to suggest that the only reasonable action is to shut down netnews
>and switch to some "safe" OS like VMS

Nor would I agree that VMS has any particular features to suppress computer
virus/trojan-horse programs, nor much anything else besides marketing hype
and a few questionable hacks (like very-long-passwords-as-if-you-could-get-
people-to-use-them-or-even-exhaustively-search-8-characters.)

	-Barry Shein, Boston University

greg@utcsri.UUCP (Gregory Smith) (04/13/86)

Instead of using 'shar' to pack stuff, and 'sh' to unpack them, why not
just have *two* programs, one to pack and one to upack? ( maybe 'mar'
for 'mail-archive', and unmar).

Obviously, when you run a shar, you are handing conrol over to unknown
forces - a shar file could contain anything.
'unmar', on the other hand, would just read the 'mar' file and create
new files. No fuss, no  muss, safe.

Of course, nasty people could still put nasty things in the actual
* code *... but that's another question. At least this way you would
only have one level to check.

One of the advantages of the current 'shar' system is that there is
no problem with mismatched versions at opposite ends - there only
is one end. But the function of the 'mar' program should be simple
enough that it wouldn't be modified a lot, no?

An idea, anyway.

-- 
"If you aren't making any mistakes, you aren't doing anything".
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg

wagner@utcs.uucp (Michael Wagner) (04/13/86)

The suggestion was made to write new tools 'mar' and 'unmar'
(for mail-archive).

How about using the software tools 'archive' as a way of sending
things around the network.  It already exists,
(in several languages), gives file names and character counts, and checks
for existing files before overwriting them.  Seems like it covers most
of the ground of most the SHAR archives I've seen.

Michael

gam@amdahl.UUCP (G A Moffett) (04/14/86)

In article <947@kitty.UUCP> larry@kitty.UUCP (Larry Lippman) writes:

> 	... There is a valuable lesson to be learned here: NEVER, EVER blindly
> unshar ANYTHING unknown!  After all, the shar source COULD have contained
> something like ``rm -fr''....

And fortunately, the shell provides a nice way to check what sorts
of things a shar will do.  For example:

	sh -x -n foo.shar

or more verbosely:

	sh -v -n foo.shar

The '-n' means "look at it, but don't do it."  Visit your
freindly manual page for more details.
-- 
Gordon A. Moffett		...!{ihnp4,seismo,hplabs}!amdahl!gam

"The unexamined life is not worth living for Mankind."
--
[ This does not represent Amdahl Corporation ]

twb@hoqax.UUCP (BEATTIE) (04/14/86)

I concur with your point 100%! (and we all know how painful that can be)

Just a side note:

> 	I have utilized many source postings from the Net in shar format,
> but have ALWAYS examined the ENTIRE shar file for ``funny business'' using
> an editor before executing it.  This really doesn't take very long to do,
> since the file has to be edited to strip the header anyhow.
            ^^^^^^^^^^^^^^^^^^^^^
The unshar I use strips off the header all by itself.
(Perhaps it should "look" for ``funny business'' as well :-)

I must admit I have unshar-ed files without looking at them closely.
So far I've been lucky - I think I'll quit while I'm ahead.
Tom.

drews@utrc-2at.UUCP (Drew Sullivan) (04/14/86)

I even have a pair of shell scripts that will build and take apart a subset
of the format.  For those of you who don't know the format:
<archive ::= <hdr> <body>
         |   <archive> <hdr> <body>
<hdr>    ::= "#-h-" <filename> <size_in_chars>
<body>   ::= text
----------------cut-here-for-sw-tools-arhive---------------
#-h- bar 134
#
#	bar -- build software tools archive.
#
for i in $*
do
	cnt=`wc -c $i`
	echo '#-h-' $i `expr "$cnt" : " *\([0-9]*\)"`
	cat $i
done
#-h- dar 210
#
#	dar -- dearchive a software tools archive.
#
#	(this is done by making it look like a shar archive file)
#
( cat $* | sed 's/#-h- \([^ 	]*\).*/#!EOF\
cat >'\''\1'\'' <<'\''#!EOF'\''/';  echo '#!EOF' ) | sh
----------------end-of-arhive--------------------------------
 -- Drew Sullivan, Systems Software.
    ...utzoo!yetti!utrc-2at!drews
-- 
  -- Drew.

geof@imagen.UUCP (Geoffrey Cooper) (04/15/86)

Most shar files use the hack of having sed put a 'X' at the beginning
of every line in the files to be extracted.  This makes it impossible
for the "termination string" to appear in the file and screw things
up.  This kind of shar file is easy to check for trojan horses.  Just
run:
	grep '^[^X#]' file.shar
and grep will print out all the lines of the shar file that are actualy
executed as commands by the shell. Then you can scan the (usually short)
list and immediately see that:
	reasonable commands are being used (sed, echo, cat).
	i/o redirection is to files only within the current directory.
in which case, things are probably ok.

If the file doesn't use the 'X' convention, you'll find out as your
screen fills up with the entire contents of the archive.

- Geof Cooper
  Imagen

mbr@aoa.UUCP (Mark Rosenthal) (04/15/86)

In article <1439@garfield.columbia.edu> dupuy@columbia.UUCP (Alex Dupuy) writes:
>    Another thing which can be done in the short term is to unshar programs
>with something other than sh. ...
>I have
>some ideas on making it secure, including running suid to some innocuous user,
>limiting the programs which will be exec'd to cat, sed, wc, chmod, or uudecode,
>and always running in an empty subdirectory.  If anyone has other ideas, I'd be
>glad to hear them.

Another idea.  Don't just run it in an empty subdirectory.  Chroot to that
subdirectory.
-- 

	Mark of the Valley of Roses
	...!{decvax,linus,ima,ihnp4}!bbncca!aoa!mbr
	...!{wjh12,mit-vax}!biomed!aoa!mbr

dave@runx.OZ (Dave Horsfall) (04/17/86)

Personally, I don't blindly unshar a file any more than I blindly compile & run
somebody else's program.  If I didn't write it, I generally don't trust it!
--
Dave Horsfall VK2KFU	 ISD: +61 2 438-1266   VTL: 248181000
Lionel Singer Group	 STD:  (02) 438-1266
20 Waltham St		ARPA: munnari!pta.oz!dave@SEISMO
Artarmon  NSW  2064	UUCP: seismo!munnari!pta.oz!dave
AUSTRALIA		 ACS: dave@pta, dave@elecvax, dave@runx
"Being paranoid doesn't mean the whole world isn't out to get you"

jpn@teddy.UUCP (John P. Nelson) (04/17/86)

In article <2555@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes:
>Instead of using 'shar' to pack stuff, and 'sh' to unpack them, why not
>just have *two* programs, one to pack and one to upack? ( maybe 'mar'
>for 'mail-archive', and unmar).

I would support this, except for the problems it would cause.  Does anyone
remember how often the request for "How do I unrotate jokes" use to be
posted on net.jokes until the unrotate program was built into news?  This
would be more of the same, but worse.

This net is made up of a largely transient population - Universities and
Fast moving high-tech companies.  Unless the "unshar" program is posted
periodically, or is actually built into a widely-distributed version of
news, each posting will result in a large number of new users who will not be
able to extract the files from the archive.

This is "Shar"'s one strength - no special program besides the "Universally
Available" Borne shell is required (besides some commonly available UNIX
tools).  Of course, a special program is required to PACK a "shar" archive -
but this is much less of a problem - a person distributing software tends to
a bit more sophisticated than the average person USING a distributed package.

A reasonable substitute for shar would be the Berkeley "Portable AR" format,
which unfortunately has not been adopted by AT&T (at least not by System V,
maybe V.2?).  It is a simple enough format that a program can be written to
extract files for those without a "portable" AR  (in fact, I vaguely remember
someone DID do this several years ago - I'll have to root around in my old
net.sources tapes).  It does not provide any directory heirarchy capability,
nor does it allow for automatic uuencode/uudecode of binary files, which
a good shar replacement should be able to do.

As long as we ARE using shar format, the first rule MUST be:  Don't unshar
anything as ROOT!!!!

John P. Nelson, Moderator, mod.sources
(decvax!genrad!panda!jpn  seismo!harvard!wjh12!panda!jpn)
Send source code to panda!sources, requests to panda!sources-request

bde@ihlpl.UUCP (Ewbank) (04/17/86)

> > [comments on April Fools Joke(?)]
> [brainstorming on how to shar safely]

what about a different approach.  post (on mod.sources) a pair of
programs, multiplex and demultiplex.  instead of using shar archives,
use these to post and extract programs from net.sources etc.

Multiplex would take a list of file names, and produce (for instance)
a file that contained lines starting with "F" and lines starting with
"D".  A line starting with "F" would indicate that this is a new file,
and the rest of the line would be the file name.  Lines starting with
a "D" would contain data to be placed in the most recently named file.

Demultiplex would take a file output from multiplex, and create the
given files.  Require relative pathnames.  Maybe only file names
instead of paths.

This would allow the same ability to transmit files without the danger
of malecious mischief.
-- 
"experience is what you get when you don't get anything else"
-- Bryan Ewbank, 312/979-4296, ...!ihnp4!ihlpl!bde,
   ih 6M-523 / AT&T Bell Labs / Naperville, IL  60566 / USA

os848@homxb.UUCP (M.AJEMIAN) (04/20/86)

About the X that many shars put in the first column...

> Most shar files use the hack of having sed put a 'X' at the beginning
> of every line in the files to be extracted.  This makes it impossible
> for the "termination string" to appear in the file and screw things
> up.  This kind of shar file is easy to check for trojan horses.  Just
> run:
> 	grep '^[^X#]' file.shar
> and grep will print out all the lines of the shar file that are actualy
> executed as commands by the shell...

You can fool this with

	X=anything rm -fr *

I prefer

	sh -x -n file.shar

Pat Wood
Pipeline Associates, Inc.
ihnp4!whuxn!phw5!phw
attunix!whuxn!phw5!phw

os848@homxb.UUCP (M.AJEMIAN) (04/20/86)

> Another idea.  Don't just run it in an empty subdirectory.  Chroot to that
> subdirectory.

chroot will require that all programs that the shar uses be accessible, meaning
you'll have to create a bin directory in the area where you want to create
incoming files and link in cat, mkdir, sed, the shell, etc.  Also, note that
not all UNIX ports either have chroot() or implement it properly.  I'm not sure,
but someone tells me that the old Zilog Zeus ports of Sys III allow you to use
../../anything to get out of the new root directory.  Anyone know if this is
true or not?

Pat Wood
Pipeline Associates, Inc.
{ihnp4, attunix} !whuxn!phw5!phw

mark@cbosgd.UUCP (Mark Horton) (04/20/86)

In article <2511@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes:
>A reasonable substitute for shar would be the Berkeley "Portable AR" format,
>which unfortunately has not been adopted by AT&T (at least not by System V,
>maybe V.2?).  It is a simple enough format that a program can be written to
>extract files for those without a "portable" AR  (in fact, I vaguely remember
>someone DID do this several years ago - I'll have to root around in my old
>net.sources tapes).  It does not provide any directory heirarchy capability,
>nor does it allow for automatic uuencode/uudecode of binary files, which
>a good shar replacement should be able to do.

To set the record straight, the portable archive format was invented by
Dennis Ritchie (I think) and adopted by Berkeley.  System V Release 2
also uses this archive format, as does V8.  So it's widely (but not quite
universally) available.

A couple years ago, some members of the UUCP project wrote public domain
programs to encode and decode these programs (par and unpar, they were
called.)  I think they were written by Paul Bame and Bill Welch.  These
programs were distributed back then.  Only problem is my copy of Bill's
unpar program has disappeared from my machine.  If someone has a copy
(are you out there, Bill?  Mail is broken from cbosgd due to broken
phone lines, so I can't just send you mail) we can assemble them and
post them again.

John points out some of the disadvantages of the portable archive format.
The overwhelming advantage at the time is that, for lots of very small
files, unpar is MUCH faster than the shell.  Also, par preserves the owner
and the write date.

	Mark

ken@rochester.ARPA (Ipse dixit) (04/20/86)

The only foolproof way I can see is to use a special unshar program.
Someone pointed out that this would have to be distributed. What the
heck, if you are going to do that, why not go to a format like the
afio(1) program that someone was going to post to mod.sources.

One approach would be restrict sh somehow. I experimented with putting
PATH=/u/user/mybin; readonly PATH in the front of a shar file. mybin
would contain only "safe" commands like cat. But a malicious person
could put /bin/rm -fr / in the file and this wouldn't work. Besides, if
you are going to edit the shar file, you should give it a once over
anyway.

The gist of it is, as long as sh is used to unshar, it is unsafe.

	Ken
-- 
UUCP: ..!{allegra,decvax,seismo}!rochester!ken ARPA: ken@rochester.arpa
Snail: CS Dept., U. of Roch., NY 14627. Voice: Ken!

dave@lsuc.UUCP (David Sherman) (04/20/86)

Those of you who see shar-started rm -rf / as the major danger from
posted sources are forgetting two things:

1. The C code can be as dangerous as the unpacking commands.
2. There are other dangers than simply having data destroyed.
   Remember the story of the Trojan horse? It came complete
   with people inside who unlocked the gates at night.

Let's look at some code from our modern-day troj_horse.c:

   system("at 8pm june 15<<EOF\necho quickroot::0:0::/:>>/etc/passwd\nEOF");

This little one-liner, if run by root, would unlock the gates at night.
It might be combined with a request from the poster to send him mail if
you install his package, so he knows who's using it (and when he can tap in).
Of course, if your system doesn't allow UID=0 logins on phone lines,
you're protected against this particular example, though not against
some more subtle ones.

Now, do you read all the code in everything you run from *.sources?
If you installed RFS, or emacs, or xlisp, or some other big package,
I bet the answer is no. And if you split up the above line into little
chunks which are strung together by an obscure routine, it probably
wouldn't be noticed on a cursory skim.

Remember Troy!

Dave Sherman
The Law Society of Upper Canada
Toronto
-- 
{ ihnp4!utzoo  pesnta  utcs  hcr  decvax!utcsri  } !lsuc!dave

bzs@bu-cs.UUCP (Barry Shein) (04/20/86)

You can probably make file distribution more secure by replacing the
very general shar with something more specific and less powerful, but
what are you going to do about the software contained therein?

Doesn't seem worth the effort to destabilize everything to not solve
the problem. Security blankets can be dangerous too.

	-Barry Shein, Boston University

mason@ryesone.UUCP (Dave Mason) (04/20/86)

> And fortunately, the shell provides a nice way to check what sorts
> of things a shar will do.  For example:
> 
> 	sh -x -n foo.shar
> 
> or more verbosely:
> 
> 	sh -v -n foo.shar
> 
> The '-n' means "look at it, but don't do it."  Visit your
> freindly manual page for more details.
> -- 
> Gordon A. Moffett		...!{ihnp4,seismo,hplabs}!amdahl!gam
> 
Unfortunately (at least on this system (sysV on IBM Series/1))
	sh -xn 		- doesn't display anything, as -n says don't execute
			  so -x doesn't have anything to print
and
	sh -vn		- displays the whole file

Does it work better elsewhere?  I was all ready to make this the default
mode in unshar (unless you give a directory for it to use), but the behaviour
isn't what we need.  I may do it anyway here (after hacking sh to make -xn
do what it should).
-- 
usenet:	..!utzoo!ryesone!mason	Dave Mason, Ryerson Polytechnical Institute
	..!utzoo!utcsri!mason	Dave Mason, U. Toronto CSRI
CSNET:	mason@Toronto
ARPA:	mason%Toronto@CSNet-Relay
BITNET:	FCTY7053@RYERSON.BITNET

gam@amdahl.UUCP (G A Moffett) (04/21/86)

In article <3029@amdahl.UUCP> I said:

> And fortunately, the shell provides a nice way to check what sorts
> of things a shar will do.  For example:
> 
> 	sh -x -n foo.shar
> 
> or more verbosely:
> 
> 	sh -v -n foo.shar

I was mistaken in my suggestion to use these two.  Their effects are
not what I expected them to be:

First of all, the flags must be grouped together.  If the first arg
begins with '-', the shell expects it to contain *all* flags to be
passed to it.  "sh -x -n ..." produces (ultimately) "-n: cannot open".

Secondly, the form "sh -x -n" (properly, "sh -xn") has little effect:
the "-n" overrides what the "-x" option tells it to do, and so nothing
is printed except environment variable assignments.

Thirdly, the last example is equialent to "cat foo.shar".  This is not
so bad as it seems, since you should probably read the shell script
before you run it, if you are suspicious of what it might do ....

This is the behavior of the shell in System V.  I tried this on a V7
(Unisoft) system and it behaved similarly.

Credits: E. Leeper (mtgzz!ecl) and Mark Brader (lsuc!msb) brought these
things to my attention.  The error is mine in not actually *testing*
what I thought would solve the problem.  I will be more cautious in the
future and test my suggestions before dropping them on an unsuspecting
public.
-- 
Gordon A. Moffett		...!{ihnp4,seismo,hplabs}!amdahl!gam

"Life's a bitch and then you die."
--
[ This does not represent Amdahl Corporation ]

j@utah-cs.UUCP (J Lepreau) (04/21/86)

Here're the contents of our "Extract" tree that we sometimes chroot into to
unshar.  Experience has shown that these files are necessary and sufficient.

777 /tmp
555 /bin owner root, contents:
[	chmod	diff	ln	mkdir	rm	sed	sum	unshar
cat	csh	echo	ls	pwd	rmdir	sh	test	wc

rjk@mrstve.UUCP (Richard Kuhns) (04/21/86)

Am I being naive in suggesting that cpio be used?  While ar-archives are
not necessarily compatible between different machines (most obvious to me
when I tried to move an ar-archive from an AT&T 3b2 to a 3b1), ASCII cpio
archives seem to travel OK.  In addition, it would be fairly simple to
extract files from the archive, as follows:

#shell script to extract an ASCII cpio archive
cpio -icvd <<end_of_archive

[ASCII cpio archive]

end_of_archive
#end of shell script

While there is still the possibility of including some `nasty' commands,
it would be much easier to check for them since there should only be
ONE (or very few, at any rate) command executed in the script.

If I've overlooked some obvious problem, please break it to me gently -- I'm
a very sensitive person :-)...
-- 
Rich Kuhns		{ihnp4, decvax, etc...}!pur-ee!pur-phy!mrstve!rjk

mark@cbosgd.UUCP (Mark Horton) (04/22/86)

In article <243@mrstve.UUCP> rjk@mrstve.UUCP (Richard Kuhns) writes:
>
>Am I being naive in suggesting that cpio be used?  While ar-archives are
>not necessarily compatible between different machines (most obvious to me
>when I tried to move an ar-archive from an AT&T 3b2 to a 3b1), ASCII cpio
>archives seem to travel OK.  In addition, it would be fairly simple to
>extract files from the archive, as follows:
>
Seems like a good idea, but cpio won't work.  Some problems:

cpio files are not necessarily vanilla ASCII text, so mailers can step
on them.

cpio files are sensitive to the exact byte counts, so the hand editing
that has to be done (e.g. removing headers) might mess it up.  The
editor might alter the image a bit too.

Not all versions of UNIX come with cpio.  4.2BSD doesn't have it (because
it wasn't in 32V, so Berkeley isn't allowed to include it unless they
check that you have a System III or V license.)  Sun's UNIX comes with
a cpio command which doesn't work.  Some older cpio's don't support the
-c option.  NOBODY defaults to -c, so users would be confused.

Similar arguments can be made for/against tar, which at least has the
power of the P.1003 standard behind it.  But it seems that the 3B2
and PC/IX don't come with tar, for some unimaginable reason.  Everything
else does, at least so far.

Also, ar archives actually ARE portable among machines running genuine
SVr2, 4BSD, or V8.  Evidently the 3B1 isn't fully SVr2 compatible.

allyn@sdcsvax.UUCP (Allyn Fratkin) (04/23/86)

In article <243@mrstve.UUCP>, rjk@mrstve.UUCP (Richard Kuhns) writes:
> Am I being naive in suggesting that cpio be used?  
> 
> If I've overlooked some obvious problem, please break it to me gently -- I'm
> a very sensitive person :-)...

Unfortunately, you have overlooked something.  cpio -...c for reasons that
are not entirely clear to me, places a NULL at the end of the file name.
This fact alone makes it useless for most mail traffic because many
systems will remove the NULL.

If cpio had only left out the NULL, you would have a portable archive.
Still, this would not be as useful as shar because many sites do not have
cpio.
-- 
 From the virtual mind of Allyn Fratkin            allyn@sdcsvax.ucsd.edu    or
                          UCSD EMU/Pascal Project  {ucbvax, decvax, ihnp4}
                          U.C. San Diego                         !sdcsvax!allyn

 "Generally you don't see that kind of behavior in a major appliance."

gnu@hoptoad.UUCP (04/23/86)

Someone has already announced the intention of cleaning up their
current "safe unshar" program and posting it to mod.sources soon.
What I suggest is that this program be made very easy to run from
the news reading interfaces, so it WILL be used from the news
reading interfaces.  E.g., in vnews, an article in a recognized
"shar" format would not show the code, but would show the top of
the message, a list of filenames in the shell archive, and the Readme
[if one exists].  A simple command would save the files in a
specified directory, already un-shar-ed.

This has many of the advantages we now enjoy:  You can always unpack it
with a text editor, or with a Unix shell, but you can also unpack it
safely "if you have the decoding program".  Since the decoder comes
with news, most people will have the decoder and will thus be safe.
The rest of the world won't be out in the cold though.  Also, having
the news readers recognize one or a few standard shar formats (and
display only the relevant info) will help automate the process of
receiving software from the net -- it will look like an "attachment" to
a text message (like receiving a source tape with a cover letter, and
running "tar" on it without having the raw tar file spewed at your
screen).

I agree that no program can prevent trojan horses -- you just have to
read and understand the code you get.  On the other hand, because any
door can be broken down is no reason not to lock it.
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa

phil@amdcad.UUCP (Phil Ngai) (04/23/86)

In article <2039@cbosgd.UUCP> mark@cbosgd.UUCP (Mark Horton) writes:
>Similar arguments can be made for/against tar, which at least has the
>power of the P.1003 standard behind it.  But it seems that the 3B2
>and PC/IX don't come with tar, for some unimaginable reason.

I used a 3B2 (awful to be believed)/400 a month ago and it did have
tar. No csh, however. Awful, awful.


-- 
 A woman who would rather have beauty than brains because men supposedly
can see better than they can think had better settle for beauty because
she clearly doesn't have much in the way of brains.

 Phil Ngai +1 408 749 5720
 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.dec.com

mykes@3comvax.UUCP (Mike Schwartz) (04/24/86)

I am not a lawyer, so I do not know if there is any legal basis for this, but...
Shouldn't somebody track down the guy who posted the trojan horse and 
prosecute?  Seems to me it is a form of computer crime, like ripping off a
bank via it's computer, or breaking the security systems of computers.

Then we can all use sh like we have been - it works best because it is
so universally possible to unarchive.

Maybe someone thought it was funny, but being prosecuted would wipe that
smile off his face.

mike schwartz
3Com Corp., Mountain View CA
(my own opinions, etc., etc.)

grr@cbmvax.cbm.UUCP (George Robbins) (04/24/86)

In article <482@3comvax.UUCP> mykes@3comvax.UUCP (Mike Schwartz) writes:
>Shouldn't somebody track down the guy who posted the trojan horse and 
>prosecute?  Seems to me it is a form of computer crime, like ripping off a
>bank via it's computer, or breaking the security systems of computers.
>
>Maybe someone thought it was funny, but being prosecuted would wipe that
>smile off his face.
>
>mike schwartz 3Com Corp., Mountain View CA

NO!  The guy already had the smile wiped off his face when he posted a
message to the whole net apologizing for his inadequately considered
action.  Note that the shar did not actually destroy any files!

All the discussion is really about the possibility of really harmful
scripts being posted, and what to do about it.  The answer is to look
at free software, before blindly trying to install it.

It really doesn't hurt to be reminded once in a while that there are
potential security problems with the net, and that it is up to each
site to evaluate the various security/convienience tradeoffs.

-- 
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)

jimb@amdcad.UUCP (Jim Budler) (04/25/86)

In article <482@3comvax.UUCP> mykes@3comvax.UUCP (Mike Schwartz) writes:
>Shouldn't somebody track down the guy who posted the trojan horse and 
>prosecute?  Seems to me it is a form of computer crime, like ripping off a
>bank via it's computer, or breaking the security systems of computers.
>
>Maybe someone thought it was funny, but being prosecuted would wipe that
>smile off his face.
>
>mike schwartz
>3Com Corp., Mountain View CA
>(my own opinions, etc., etc.)

Give the poor guy a break, not a heart attack!!!

	1. He already apologized.

	2. His 'trojan horse' did not do any actual damage to anything, it 
	just announced that it was.  It replaced the users .login with a 
	script which made some horrifying announcement, but it saved the 
	.login in a backup.  

	

-- 
 Jim Budler
 Advanced Micro Devices, Inc.
 (408) 749-5806
 Usenet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb
 Compuserve:	72415,1200

bzs@bu-cs.UUCP (Barry Shein) (04/25/86)

am i missing something or is this fantasy of a mythical 'sh -xn file'
which shows you exactly what a shar file will do w/o doing it just that,
a fantasy.

Consider:

touch foo.bar
if [ -f foo.bar ]
then
	whatever
fi

how will this -xn flag know that foo.bar should exist at this point?
by simulating the entire unix system? sounds tough, sort of a 1-1 map
of the world.

Unless I miss something, save your time for thinking about another approach.

	-Barry Shein, Boston University

pete@stc.co.uk (04/28/86)

Expires:
Sender:
Followup-To:
Distribution:
Keywords:
Xref: ukc net.news.adm:575 net.news.sa:247 net.sources.d:125
Xpath: ukc eagle

An analogy:

        A man was walking down the street and passed a jeweller's
shop. Looking in, he noticed that there was a tray of rings on the
counter and apparently no one about. There were three things he could
have done :-

        He could have carried on and ignored the situation.

        He could have walked in, pocketed the rings, and walked out
        again.

        He could have gone in, left a note on the tray saying "I
        might just take these rings next time", and walked out.

The man took the third option.

The jeweller, on discovering the note, got really upset.

"How dare this man just walk into my shop and do what he likes! He's
a criminal!"

But he took more care of his shop thereafter. And the real thieves,
who had been casing the joint anyway, went elsewhere.
-- 
        Peter Kendell <pete@stc.co.uk>

        ...!mcvax!ukc!stc!pete

        "If I could only be tough like him,
	 Then I could win,
	 My own,
	 Small,
         Battle of the sexes."

chriso@3comvax.UUCP (05/01/86)

In article <196@gilbbs.UUCP> mc68020@gilbbs.UUCP (Tom Keller) writes:
Flames about what a bad SA Mike Schwartz is for posting article
<482@3comvax.UUCP>, where mykes@3comvax.UUCP (Mike Schwartz) writes about
the possibilities of prosecution of the april fool's poster.

I just want to clarify that Mike is not now (nor has he ever been) the SA
of 3comvax. Rather, he was making a provocative suggestion (a hobby of
his) and posting it to the net. I talked to Mike, and not only did he not
unshar the posting in question, he did not know that source addresses on
postings could be faked.

Sorry about the net.clutter, but I could not let Tom's comments go
unanswered, particularly after his flame about IBM pc postings in
net.micro.pc. Tom, quit bitching about how bad your environment
(braindamaged compiler esp.) is. Nobody forced you to get it, and no one
wants to hear your complaints. If you dislike the USENET as much as your
postings seem to indicate, drop off!

(ahem, the above seems to be a flame... Oh Well!)

	Chris Olds	{ihnp4,hplabs,glacier}!oliveb!3comvax!chriso
				(paths via bnrmtv!3comvax also work)

The above views reflect those of the real SA of 3comvax, but only due to
the coincidence that we are on a same-name basis.