Path: utzoo!mnetor!uunet!munnari!murdu!u3369429
From: u3369429@murdu.OZ (Michael Bednarek)
Newsgroups: comp.os.vms
Subject: The dangers of VMS_SHAR
Message-ID: <1335@murdu.OZ>
Date: 7 Jan 88 02:28:56 GMT
Followup-To: comp.os.vms
Organization: I.A.E.S.R., Melbourne University
Lines: 77
Keywords: virus trojan_horse vms_shar
Summary: Watch out!

bryce@hoser.berkeley.EDU (Bryce Nesbitt) writes in RISKS 6.2 :

>Subject: Viral VAXination? (Re: RISKS-6.1)
>
>>      (Martin Minow THUNDR::MINOW ML3-5/U26 223-9922)  writes:
>>
>>Could a "harmless"  CHRISTMA-like virus attack a VAX/VMS system?   A
>>recent network posting (RISKS?, LINKFAIL?) mentioned the possibility of a
>>virus  hidden in SHAR files which are _executed_ as .COM  files to unpack
>>them.
> 
>I'm surprised nobody has mentioned this:  Around here we don't "execute"
>shar files to unpack them.  Instead there is a handly little utility called
>"unshar".  I use a version on both Unix and my Amiga microcomputer.  It
>internally handles all of the "legitimate" commands that a simple file packing
>shar might contain (echo, wc, cat, if, test, #, exit, etc.).
> 
>It is much less vulnerable to attack.  To use the example of the poster, unshar
>would simple report "unknown command" if a "SET PROC/PRIV=ALL" was quietly 
>inserted in the middle of the file.
> 
>The comp.sources.unix and comp.sources.misc archives undoubtably have C
>source code for the taking.

Now, I'm no UN*X guru, but I understood that `shar' files would be unpacked
by feeding them to a shell, as in `sh <foo.shar'. The underlying idea was
a self-unpacking file. (BTW, the `unshar' you mention doesn't unpack properly
all shar files; see the recent posting of DropCloth to comp.binaries.amiga.)

It was with this ambition that I wrote VMS_SHAR, a procedure which creates
self-unpacking files.

Recent events have made it clear that it can be very dangerous to execute
procedures which you haven't inspected. Instead of silently hoping that no-one
will notice, I'd rather like to warn people of the dangers of executing
procedures they receive over the net or via mail.

Please, take the time to read every procedure before executing it!
It is dead easy to include some really nasty commands in a VMS_SHAR'ed file,
and it is not easy to check for them.

     o Despite claims to the contrary, DCL commands need not to begin
       with a `$' sign, so watch out for anything fishy, like del, priv, etc.

     o Watch out for cryptic symbol definitions, e.g.:
       foo[0,32]=%X454C4544 
       These symbols are usually only necessary to define control characters,
       like `ESC[0,8]=%X1B'
       not  - as above -  `DELE'. The same effect may be produced by:
       foo[0,32]=1162626372
       
     o Assume the worst if you see a procedure where `verify' is forced off.
       Similarly, an unpacking procedure should not attempt to handle CTRL-Y.

     o Execute the procedure in an unprivileged account, in an empty sub-
       directory. Turning off your privileges is not sufficient.

     o Sometimes even typing files can be slightly dangerous. In my more
       childish days and when we still had FINGER on our VAX, I had a PLAN
       file which contained `<ESC>c' (Hard terminal reset) and effectively
       logged anyone out doing a FINGER on my name.

     o Don't trust the `From:' field. Both UN*X and VMS can be fooled
       about the identity of the sender.

No technical measure can be devised to exclude viruses, Trojan horses, etc.
Your alertness is the only defense.

And if you have been burnt, PUBLISH IT! Immediately! Naming names!

Michael Bednarek
Institute of Applied Economic and Social Research (IAESR)
Melbourne University, Parkville 3052, AUSTRALIA, Phone : +61 3 344 5744
Domain: u3369429@{murdu.oz.au | ucsvc.dn.mu.oz.au}  or  mb@munnari.oz.au
"bang": ...UUNET.UU.NET!munnari!{murdu.oz | ucsvc.dn.mu.oz}!u3369429

"POST NO BILLS."