Conference noted::hackers_v1

	.title	 SETOFF	Disable User Privileges
	.ident	/X0100A/
;+
; **-SETOFF-Disable User Privileges
;
; This routine is used to cancel authorized privileges. It is useful for
; running executable images from a privileged account when you havn't
; checked the sources (e.g. games). To get your priviliges back, you
; have to log out.
;
; Theis program sets your authorized privileges to your current process
; privileges. To run this program you need either CMKRNL or SETPRV in
; your authorized privilege mask.
;
; This program is for use under Version 3 of Vax/Vms only.
;
; Assemble:
;	MACRO SETOFF
; Link:
;	LINK SETOFF
; Run:
;	SET PROC/PRIV=(Required privileges only)
;	RUN SETOFF
;
; Version:	1
;
; Original:	00A	Date:	 4-SEP-1984	Author:	Hugh A. J. Kennedy
;
;-

	.sbttl	Misc Macros & Definitions

	.library /sys$library:lib.mlb/
;
; Misc Definitions
;
	$jpidef				; Define job parameters.
	$pcbdef				; Define PCB offsets.	
	$phddef				; Define Process Header offsets.
	$prvdef				; Define privileges.
;
; Local Macros
;
.macro	jobpar	.item,.length
;+
; **-JOBPAR-Collect Job Parameter
;
; This macro is used to specify a parameter and a size which is used
; to allocate some space in the common area JPIBUF to receive it.
;
;	ITEM	Item code consisting of the parameter name without
;		the JPI$_ prefix. These are listed under the $GETJPI
;		system service.
;
;	LENGTH	Length in bytes to allocate.
;-
	.word	.length
	.word	jpi$_'.item
	.save
	.psect	jpibuf
jpi_'.item':
	.blkb	.length
	.restore
	.address jpi_'.item
	.long	0
.endm	jobpar

	.sbttl	Misc Data Areas

;
; Pure Data Areas
;
	.psect	pured,con,noexe,lcl,nopic,shr,rd,rel,nowrt

;
; Job Parameter Common (accessible from Fortran-77)
;
	.psect	jpibuf,ovr,noexe,gbl,pic,shr,rd,rel,wrt,long
;
; Job parameters to be collected.
;
jpilst:

;
; COMMON /JPIBUF/
;
	jobpar	procpriv,8		; Process privileges.
	.long	0			; Mark end of list.
;
; Misc. Pure Data
;

knlprv:					; Privilege Needed To Run.
	.long	<1@prv$v_cmkrnl>
	.long	0

;
; System Services
;
getjpi:	$getjpi -			; Get job parameters...
		itmlst=jpilst		; Using fixed item list.
setprv:	$setprv	- 			; Set privileges.
		enbflg=1,-
		prvadr=knlprv

;
; Impure Data
;

 	.psect	jpibuf
;
; Results Of GETJPI Go Here...
;

	.psect	impurd,con,noexe,lcl,pic,rd,wrt,rel
;
; System Service Argument Blocks
;

;
; Misc. Impure Data
;

	.sbttl	Start Of Code
	.psect	purec,con,exe,lcl,pic,shr,rd,rel,nowrt 

	.entry	setoff,^m<>
;
; Get Current Process Privileges
;
	$getjpi_g getjpi		; Issue directive.
	blbc	r0,10$			; Any problems?
;
; We need CMKRNL to disable Authorized Privs
; 
	$setprv_g setprv		; Ask for CMKRNL.
	blbc	r0,10$			; If problems - exit.
;
; Carry Out Our Magic
;
	$cmkrnl_s clrprv		; Execute Kernal Rtn.

;
; Return
;
10$:	$exit_s	r0			; Quit the Program.

	.entry	clrprv,^m<>

	movl	pcb$l_phd(r4),r1	;; R1 -> Process header.
	movq	jpi_procpriv,phd$q_authpriv(r1) ;; Reset authorized privs.
	movzwl	#ss$_normal,r0		;; Return success.
	ret				;; Exit back to USER MODE.
	
	.end	setoff

SIGH - all the 'trojan horse' does is WRITE YOU A LOGIN.COM FOR NEXT TIME
YOU LOG IN!

Doesn't need privileges.  

Uses the ones you get when you log in, not the ones you carefully disabled
while you ran the game.




Another great idea bites the dust.


/Bevin

	Re: V4 privileges.

	I think V4 has addressed this problem by looking at your
current privileges when it does a SPAWN.  Maybe someone has looked into
this more, but here's what I remember:

	I was debugging some random program on an account with SETPRV
as an authorized privilege, but not a default privilege.  I typed a ^Y
and SPAWNed a subprocess, but I could not get the subprocess to set the
privs I needed for what I was doing.   If this feature is part of $CREPRC,
not part of the SPAWN command, then it is likely that the trojan horse
could not spawn a process with more privs than your current process.

	Although it might be able to create a detached (vs sub) process
with any of your authorized privs set.

	Anyone know for sure or care to check it out?

	KC

The way to get round the problem of the fake login.com is to do a quick
SET UIC [377,377] before you remove your privs. If you still want to be
able to write files, you have to arrange a directory and/or quotas for 
the alternate UIC.

The problem came to light after a little experiment with a version of
Multi-User Startrek which patched the SETPRV system service and informed
you that you had been hacked (It was intended for demonstration purposes
only).

If your Trojan Horse program is clever enough, it can hack its way into
unauthorised VAX/VMS privileges by any number of routes (See note 55).

I still don't think that anyone has answered the query of how do you find
out if you have been hacked. Tracking the use of SETPRV isn't much use when
a user can directly manipulate the privilege mask.

Do we put a CRC on all the installed images so we can test for unauthorised
alterations?

Hugh.

"Do we put a CRC on all the installed images so we can test for unauthorized
alterations?"

Not a bad idea.  On USENET a few months ago, someone mentioned that
he crc'd all his "system" files daily, comparing them with a list
that he kept off-line.

You'all might want to read the Thompson/Ritchie Turing Award lectures
in a recent CACM.  One of them (Ritchie) described the trojan horse
he put into a version of Unix that allowed anybody with a specific
password to log into any Unix machine as root (== SYSTEM).  The
code was found by someone who noticed an extra global symbol on
a load map and dumped the image to find out what was there.

It has been claimed that that particular version of Unix never
got out of Bell Labs, but you never can tell.

If I was a Unix customer and found that code on my system, I'd be
talking to my lawyer right away.

Martin.

If you are really serious about "checksumming" your files, DON'T use CRC.
It's not all that hard to make "balancing" alterations that make the CRC
come out unchanged.  CRC is a checksum meant to detect burst errors on
comm lines and disks.  It is not particularly good for anything else.  In
particular, its application to security systems is minimal.

							-- Jerry

Jerry is right -- to alter a file so that it can't be caught by
the CRC checking method:

  (1) check the CRC
  (2) change the program -- leave 1 unused word zero
  (3) check the new CRC
  (4) patch the unused word to the right thing (simple algorithm,
      based on the old CRC and the new CRC and the knowledge of
      the CRC algorithm)
  (5) the CRC is now identical to the old CRC

However, a 'secret' CRC (not using the normal algorithm) could
be used to give yourself a 'warm and fuzzy' feeling that your
file has not been modified.  ... as long as you are sure that
no-one but you knows the secret CRC algorithm.

Andy V

The hack to UNIX's login was that he modified the C pre-processor (cpp) to
recognize when it was working on login and insert code to consider a
particular password to be valid for any account. The really neat thing about
the hack was that it ALSO recognized when it was working on cpp and inserted
itself, so the sources would all look normal.

	Karl.

Re: Jerry's and Andy's Replies About CRCs

Ok, if the CRC is so insecure, do you have an alternative suggestion?
I know we could do a BACKUP/COMPARE against a backup (ideally on tape),
but this takes operator/tape drive resources.

Another problem that occurred to me is that a CRC on SYS.EXE would be
difficult to determine because you would have to exclude the parameters
altered by SYSGEN and the date and time written back to the system image
during boot. The BACKUP/COMPARE would also fall over for the same reason.

Back to my earlier question, how do we determine whether a piece of
privileged code has been altered? I have seen a recommendation that
suggests that the machine is taken off the net and the system reinstalled
from a secure copy if there is the SLIGHTEST suspicion of a hack. Has
anyone done this? Does anyone realise how much this would cost (at least
a couple of days down time, maybe more)?

Hugh.

A system I occassionally use went through a "off the net and rebuild
from SDC distributions" a while back.  Thanks to the competency
of the operations staff, it was only off for a day and a half.
(And, please note that I was not being sarcastic.  Rebuilding
a large system from scratch is a long, painful, process.)

Martin.

Re .9:

Use two different checksums of the same file.

Only the NSA would find it easier to hack the checksum than just change
the master copy, or the checksum program, at that point.
				/AHM

I had added a reply to this note to the effect that CRCs are very easy to crack.
Basically, the idea was to apply an "error pattern" to the file which would be
undetectable by any CRC.  I've recanted.  Andy Vesper is quite correct:

	However, a 'secret' CRC (not using the normal algorithm) could
	be used to give yourself a 'warm and fuzzy' feeling that your
	file has not been modified.  ... as long as you are sure that
	no-one but you knows the secret CRC algorithm.

The 'warm and fuzzy' is more iron-clad than the phrase implies.


Consider a one-bit CRC (this is equivalent to parity checking).  If the error
pattern "11" (i.e., toggle two adjacent bits) is applied anywhere in the file,
any number of times, the modification will be undetectable by any one-bit CRC.

Similarly, the error pattern "11011" will be undetectable by any two-bit CRC
(equivalently, the two low bits of the computed CRC will remain unchanged).

In general, the smallest error pattern undetectable by any n-bit CRC is:

			k
	   n	       2 - 1
	Product	( 1 + 2      )
	  k=1

This function grows fast; for n=4, this is 3*9*129*32769; for n=8, the pattern
is 503 bits in length; for n=16, the pattern is 131055 bits in length (so the
technique is applicable to files over 32 blocks in length); for n=32, the
pattern is 2**33-33 bits in length (applicable only to files of more than 2**21
blocks in length).

The larger the file being attacked, the larger the pattern may be, giving the
"cracker" more flexibility.  For example, a 2048 block file allows a pattern
undetectable by 22-bit CRCs to be applied.  Thus, the cracker has a 1-in-1024
chance of being undetected by a (single) 32-bit CRC; if two 32-bit CRCs are
used, the chances are 1-in-a-million.

Smaller files lessen the efectiveness of the cracker's technique.  For example,
with a 128 block file, only patterns undetectable by 18-bit CRCs may be applied,
and the cracker stands a 1-in-2**14 of being detected; or 1-in-2**28 if two CRCs
are used.  It may be worthwhile to store separate CRC values for each chunk of
64 blocks in the file, rather than for the file as a whole.


OF COURSE, the nature of the beast changes if either the CRC function is known,
or if the computed CRC is stored in the file.

If the CRC function is known, then it is a simple matter to compute the effect
on the computed CRC of toggling any particular bit in the file.  This effect
is simply an n-bit number which is XOR-ed with the computed CRC.  Given 64
"unimportant" bits in the file, it's a simple matter to compute how these should
be toggled to counteract the toggling of an "important" bit.  It's a boolean
matrix inversion and multiply, over the group (AND,XOR).  This was roughly how
the VMS CRC password encryption was cracked (although it was actually easier).

If the computed CRC is stored in the file (or, equivalently, if the computed CRC
must equal a known value, such as zero), it should be a relatively simple matter
to compute the CRC function, or a small set of potential CRC functions (this is
left as an excercise).  Guessing the CRC function would also work, since the
guess can be verified, but this is impractical with 32-bit CRCs.


To help ensure that the CRC functions, and the computed CRCs remain "secret", a
trap-door function (such as that used for VMS password encryption) can be used.
Some password is encrypted to yield two 32-bit CRC functions.  These are used to
generate CRC values (for each file), which are encrypted and either stored or
verified.

With this, the security resides with the secrecy of the chosen password, and
the protection of the verification program itself against modification.

(The verification program itself would be safer if it issued something better
than a "pass/fail" message -- a good possibility is to compute some function of
the CRC values of the files, and convert this value to a string, which must be
memorized).

					- Gilbert

CRC's and other such hacks only serve to challenge the perpetrator
of a Trojan Horse.  They are not effective in really stopping one.
(Since the Trojan Horse could well be in the CRC routines - the editors,
the SDC copy of FORTRAN, etc.)

The only real solution to Trojan Horses is non-discretionary controls.
VMS V4 has an unsupported partial implementation of them (full support
planned for later).  

In brief, non-discretionary controls solve the Trojan Horse problem
by breaking your system up into a mathematical lattice of access classes.
The security portion of non-discretionary controls assures that a
Trojan Horse cannot move information from a more sensitive point in
the lattice to a less sensitive point.  Thus, a Trojan Horse can steal
your information but it can't release to anyone who isn't authorized.
The integrity portion of non-discretionary controls is the mathematical
dual of security.  However, integrity prevents a high-integrity program
or database from being corrupted by the actions of low-integrity software.

How you determine whether a program is deserving of a high integrity 
level is a hard problem.  In the limit, you want to do proof of correctness
on it (if you have lots of money and are willing to wait a LONG time.)

This note isn't a good place to discuss non-discretionary controls
in detail.  For more information, see the July 1983 issue of COMPUTER
from IEEE.   It is a special issue on computer security.  You can't miss
it.  It has a Trojan Horse on the cover!

The method I described provides a fairly inexpensive double-blind method
of determining whether a file has changed, with stated bounds on the security.

It has two advantages over non-discretionary controls.  It's sensitive to
ANY changes (whether authorized or not), and it can be available tomorrow.

					- Gilbert

When someone has physical access to your computer, non-discretionary
controls become a little academic. If you can impersonate the 
identification of the update source, then by definition, as long as the
system can be updated, it can be hacked!

I too prefer the idea of some kind of file signature, like the CRC ideas
proposed.

Hugh

For what it's worth ---

The program outlined in a previous note has been coded and is described in
another notes file.

Which one?

For checksumming files, I'd prefer a different solution that requires
no secrets:

Use DES.

More specifically, run the entire file through DES with a fixed (hardcoded)
key, any old key, in cypher block chaining mode.  Save the last cypherblock
(64 bits).

When checking for hacks, use a copy of the program you keep on tape (in
executable form, with all RTL routines linked in so you can stop worrying
about hacked RTL).  Simple, secure (as secure as DES, anyway, whatever
that means).  Not very fast, well you can't win them all.

This works because DES is not a linear transformation and CBC has infinite
plaintext change propagation.

	Paul

It would be nice if a file-checker could give a short/succint result, rather
than a simple "file is okay" or "file has been hacked", since a file-checker
would be the first place to store a "logic bomb".  Furthermore, it should not
be possible for a hacker to determine this terse result based on stored values.

The problem with your description of DES CBC is that it uses a fixed key, and
stores the result of the cipher-block chaining.  Both the original file and the
stored DES result may be hacked.  Also, since the terse result is known to the
hacker, it may be possible to find a different hacked file that yields the same
terse result.

DES CBC could be used with a secret password, and the final result 'smashed' to
provide a terse result.  Then, the only advantages of the CRC approach is speed
of software implementation.

If I'd had a DES algorithm already coded, I'd have used that instead of CRCs.

					- Gilbert

Re:	.18

Just to remind you folks that according to various US 
government departments, all encryption products including any 
that use DES count as munitions. This means half a ton of 
paperwork to get it over the Atlantic, let alone sell it to a 
customer!

Although the DES algorithm is available from the appropriate 
journals, even a UK company can't code it up and market it 
without permission of that great empire across the ocean!

Hugh.

P.S.	Back in the '40s we should have classified Turing's 
stuff as strategic material - and maybe we would still have a 
native computer industry in the UK! :-)

re .20:

Do you mean to say that the US government would attempt a lawsuit
or something if a French company wrote a DES routine in PASCAL?

Sounds just like our air-head president.

Andy V

I was sent a DES in C from a person in Canada, who implemented it
from the federal registry description.   Fortran sources for Lucifer
(a DES predecessor) were published in Cryptologica.

Someone told me once that the prohibition was against selling DES
(or other encryption devices) -- but not against giving it away.
Anyone care to confirm that.

Martin.

RE: .21

I kind of doubt our "air-head" president has anything to do with DES
policies.

	Mike

 re: .22

 "Can't sell it, but giving it away is allowed..."

 Sounds like you're cutting into the Combat Zone's business...

Warning: FLAME follows.  Read at your discretion.

re .23:  The president is certainly very 'big' on reducing
technology leaks.  He has stressed this in public speeches
and the actions of the DoD have certainly reflected this. 

Some of the results: (1) It is considerably harder to get
export licenses.  (2) Many more items have been added to the
non-exportable lists.  (3) DEC must now investigate the
companies they sell VAXen to (even though this is illegal in
other countries) to satisfy the U.S. export controls.  (4)
DEC must get export licenses for each system they sell,
instead of getting a general license to sell any number of
similar systems into a particular country. (5) European
DECUS had to send a special form to all attendees requiring
them not to repeat what they heard at DECUS (for fear that
people from the USSR might overhear). (6) You cannot sell 
any implementation of DES overseas, software or hardware (it 
might be possible with a license, but we had to create a 
special version of ULTRIX with no encryption software for 
the world-wide marketplace).  (7) Universities are pressured 
to reduce access of foreign grad students to 'sensitive' 
topics (even though they are generating a good portion of 
it).

I feel that Reagan's public and private statements on the
matter are major reasons for the DoD's attitude and the 
export restrictions.

Andy V

RE: .-1

What I meant by my statement was that I am sure that Reagan has no idea
what the DES is. One of his advisers recommended that it should be put on
the "list", so what should he do, argue with him/her? What does he know?
Throw stones at the person responsible for the recommendation, or maybe
throw stones at Reagan for picking the person in the first place, but to
blame him for something so detailed as a decision to not allow DES to be
exported is a little ridiculous.

With regard to security in general. Would you agree that we need some
controls? I suspect that you would. Once you agree we need controls the
question becomes what should be controlled. I agree that they (the
government regulators) have gone too far. For example, restricting
publication of papers regarding encryption systems would seem to me to be
self-defeating, that is, if a system isn't good enough to withstand the
most elaborate scrutiny, then it just isn't good enough, period.

With regard to DEC's problems in the export market - are we being singled
out or is this policy applied across the board? I would guess the latter.
In that case the computer industry as a whole should do something to help
set up guidelines rather than simply crying rape. If we (DEC) are being
singled out then maybe we should take them (the government) to court. On
the other hand, maybe we deserve a slap on the hand. In our haste to sell
computers maybe we aren't too careful about who we sell them to. Just
speculating, since I don't know what was in the minds (and neither does
anyone else except the people involved) of the people involved.

	Mike

Okay, so we're banned from exporting encryption/decryption software, because it
might fall into the wrong hands.  All those who wish to bet that the export
ban has kept all such software within American borders may place their bets
with me.  You name the odds.

I don't recall ever being searched when I left the country.  (Only on domestic
flights!)

---Pete

The export ban is on "cryptographic devices".  Thirty years ago, everyone knew
what a "device" was.  Today, software is in the odd intermediate state:  It's
not really a DEVICE, but often the distinction is academic.  (A VAX with DES
software in it is certainly a "cryptographic device".  A VAX without such soft-
ware is not.  If you call a floppy with the software on it NOT a device, then
you've made it impossible to control export of "cryptographic devices" at all.)

The regulation was drafted in simple terms:  No "cryptographic devices" can be
exported without special permits.  This includes such things as Captain Mars
Magic Decoder Rings, presumably.  But how would YOU have worded the law so as
to allow export of such things as Rings, but not of real cryptographic devices?

DES is in a sort of funny state because the algorithm is so public.  That does
NOT mean that the technology to build effective DES encryption devices is
also public.  A simple software implementation is easy; a high-speed hardware
implementation requires a lot of high-tech work.  It might be quite reasonable
to try to control the latter.

There's a fundamental misunderstanding here of the way the law works.  The let-
ter of the law says:  If you want to export cryptographic devices, you have to
get an appropriate license.  That law, as written, will remain constant.  It
does NOT, however, specify what the requirements are for getting an export
license.  Presumably, if anyone asked for it, they'd get their license for a
Captain Mars Magic Decoder Ring right away.  For a straightforward software
implementation of DES, there would probably be little trouble.  As you get
more and more sophisticated in your implementation, it would get harder and
harder.  But this is hardly unique to cryptographic devices - the same holds
true for all sorts of electronic hardware, VAXes (quite visibly) included.

							-- Jerry

	Aiding world peace?  Didn't you hear what the Department of Defense
had to say?  Apparently the VAX has "no reasonable civilian use".
		(-: :-)
		<_Jym_>

  re: .29


  Errr, you're not going to beleive this, but a couple of months ago, waiting
at the loading bay here at DECpark (REO) was a Dutch lorry, with 'Agricultural
Equipment' written on the side in huge letters ! Unfortunately, I think
that all the gardening here is contracted out...



trev

Re:	.-1,.-2,.-3

Actually, one outfit I once did a consultancy at, are called 
the Agriculture & Food Research Council who run about 8 or 9 
Vaxen. The nearest to defence work that they did on the Vax was 
running EMPIRE and multi-user Startrek (GALAXY)!!!!

Hugh.

Actually we have our general license back, with some modifications.
Generally we can ship most things to most places as we did before.
However, we must run stringent checks on customers in places like 
Germany and Sweden because of the incidents mentioned earlier.

We now maintain a DENIED PARTIES LIST on a Videotex database in Geneva
for this purpose.



Mike

     	[RE .2]:  You can avoid this by making your LOGIN.COM file version
number 32767.  VMS V4 has some way of putting an "alarm" on a file, but I
don't know quite what that is...
#6	<_Jym_>\

Date:	    Sat, 20 Sep 86 04:17:50 EDT
From:	    "James H. Coombs"  <JAZBO%[email protected]>
Subject:    NOTROJ--it IS a trojan
 
Distribute far and wide!
(C)Nobodaddy, 1986
 
                       A Story of a Trojan Horse
            With Some Suggestions for Dismounting Gracefully
 
                                   by
                            James H. Coombs
 
 
NOTROJ.COM is a TROJAN HORSE (comes in NOTROJ.ARC--for now).
 
I first became aware of NOTROJ when a member of The BOSS BBS community
reported his belief that the program destroyed the directory of his hard
disk.  After two days of restoring his files, he concluded:
 
         This Trojan was written by a real Pro---he knows his ASM and
         uses it as a weapon---not a tool.  From lokkin' at the job he
         did on me, I tendto doubt that I would have found the bomb has I
         been smart enough to look. ---PLEASE!!!!!  Spread the word 'bout
         this one.  It's a Killer!
 
In the next couple of days, I saw a similar note on the Boston Computer
Society bulletin board.  This victim rather pathetically credits NOTROJ
with a "valiant" attempt at saving his data.
 
         The program in question is a time-bomb (about 10 minutes) and
         works by the "SOFTGUARD UNFORMAT" method of attack.  I'm not
         sure what it did, or how it did it, or even how I could have
         recovered the disk but the NOTROJ program I had in the
         background alerted me to the fact, and tried a valiant attempt
         to shut down the hard disk.  To no avail, though.
 
Since my hard disk was becoming fragmented anyway, I decided to test
NOTROJ.  Everything looked pretty reasonable from the start; in fact, the
program looks like a very useful tool (although I'm not in love with the
interface).  One loads NOTROJ resident and then accesses the options menu
through Alt-N.  The menu contains about fifteen items, some of them
annotated "DANGER", e.g., "Format track (DANGER!)".  For each parameter,
the user can select one of four responses: Proceed, Timeout, Reboot, or
Bad Command.  The menu also provides a fifth option--"Pause&Display"--
which provides the user with full information on the activity that the
currently active program is trying to perform and prompts for one of the
four primary actions, e.g, Proceed.
 
I selected "Pause&Display" for all of the DANGERous parameters.
Everything worked fine, although I found that iteratively selecting
"Timeout" in response to the "Write sectors" interrupt hung up the
machine.  I fooled around with a number of commands and finally
reproduced the disk crash.  At the time, I was running the DOS ERASE
command (I had been suspicious of that one for quite some time anyway).
I don't have the full message that the program displayed, but I did write
down this much "Softguard-style low-level disk format."  (Keep those
words in mind.)
 
In spite of the fact that I had prepared for a disk crash, it took me at
least an hour to get running again.  When I booted the machine, I was
thrown into BASIC and could not get back to the system.  I put a DOS
diskette in, and got an invalid drive error message when I tried to
access the hard disk.  Here is the recovery procedure for this and most
disk crashes:
 
1) Insert DOS system disk in drive A.
2) Reboot the machine.
3) Run FDISK and install a DOS partition on the hard disk.
4) Format the hard disk with the '/S' option.
5) Restore files from the most recent full-disk Bernoulli or tape
   backup.
6) Restore files modified since the most recent full-disk Bernoulli
   or tape backup.
 
Once I got a minimal system running, I decided to reproduce the crash to
ensure that this was not some quirk of bad programming.  What, ho!  I got
bored playing around with COPY and ERASE and a few other programs.  I
waited for a while, read a magazine--no signs of a simple timing
technique.  I began to think that NOTROJ might be more incompetent than
vicious.  Something about the documentation made it seem unlikely that
the author was a criminal.  It occurred to me, however, that the author
might have had some time to waste on this program.  Does he, perhaps,
check to see how full the hard disk is?  It would be reasonable to evade
detection immediately after a bomb by making it impossible to reproduce
the crash.  In addition, it would be much more painful for people if they
have restored all of their files or gradually rebuilt their hard disks
before they discover that this is a trojan horse.  So, I restored all of
my files.
 
This time, Norton's NU command turned out to be the great blackguard that
was trying to format my disk (according to NOTROJ--although it was only
reading the FAT).  So, I restored my hard disk.  All of the while,
however, I had the nagging feeling that the documentation did not reflect
the personality of someone vicious.  When I got running again, I took a
look into NOTROJ.COM.  Nowhere could I find the words from the message
"Softguard-style low-level disk format."  That convinced me.  I have
concealed passwords on mainframes by assembling strings dynamically
instead of storing them statically.  Our trojanette must have used the
same technique so that no one would spot the suspicious messages.  I had
counted on being able to get them directly from the program so that I
would not have to take the time to write the whole message down while my
system was being operated on.  I do recall NOTROJ patting itself on the
back, however, for preventing "further damage."
 
As I think back on it, the documentation contains something of a rant
against copy-protection schemes, including Softguard.  In addition, I had
always been troubled by the fact that the name NOTROJ is an acrostic for
TROJAN and also an assertion that the program is not itself a trojan.
The documentation is also very badly written.  One has to experiment to
make sense of it, although that is nothing new in software documentation.
Also, the style is something of a pidgin English, which seems consistent
with the fact that the author has an Oriental name (Ng, or is that for
"no good"?).  Well, since the author's name and address are listed in the
documentation, I decided to give him a call.  Mirabile dictu!  It's a
real name, and I got a real number--I just didn't get an answer, even at
2 a.m.  It doesn't make much difference anyway, there's nothing that he
can say to convince me that he had legitimate reasons for concealing
error messages and that his program is not a trojan horse.  There is also
the possibility that the person listed as author has nothing to do with
the program.  Could the pidgin style of the documentation be the work of
a clever linguist--an acrostic fan--a sick person who considers himself
to be the bozo that Sherlock Holmes was always after?  Who knows?  I have
to write a book.  No time to play with these fools.
 
So, be careful.  Note that sysops don't have the time to test every
program extensively.  If a program like NOTROJ requires that a disk be
more than 70% full, for example, a lot of people may never have any
problems with it.  What else can we do?  Does someone want to try to
prosecute the author of NOTROJ?  And how do we keep ourselves from
becoming paranoid about new noncommerical software?
 
Eventually, I think it will all shake out just fine.  Those of us who are
prepared for problems provide others with the testing and filtering.
Junk like NOTROJ just does not make it into my community.  Actually, I
find mediocre software much more of a problem.  I have spent a lot of
time and money sorting through megabytes of chaff to find but a few
grains of wheat.  I would like to see us find some way to constrict the
growth of chaff and worms both.  If we can't do this, many of us may
have to switch to commercial software.
 
--Jim
 
 
Replies may be made to:
BITNET:  JAZBO@BROWNVM
BBS:     The BOSS, BCS, Hal's, et passim
BIX:     jcoombs