Path: utzoo!utgpu!ria!pruss
From: pruss@ria.ccs.uwo.ca (? pruss)
Newsgroups: alt.hackers
Subject: Re: Execute only files on Novell
Summary: It could be done, but it is not too easy.
Keywords: execute-only, novell, nfs
Message-ID: <449@ria.ccs.uwo.ca>
Date: 8 Jun 90 13:54:18 GMT
References: <445@ria.ccs.uwo.ca> <224@rossignol.Princeton.EDU>
Organization: Applied Math, University of Western Ontario, London
Lines: 78
Approved: AlexPruss@here.there.ca

In article <224@rossignol.Princeton.EDU> tr@samadams.princeton.edu (Tom Reingold) writes:
>In article <445@ria.ccs.uwo.ca> pruss@ria.ccs.uwo.ca (Alex Pruss) writes:
>$ 
>$ The cause of this security gap seems to be the fact that for exec-only
>$ files the server queries the workstation whether it is executing
>$ the program and thus is allowed to read it, or whether it is just reading it.
>$ The workstation can, of course lie...  
>$ 
>
>I have read that the same problem exists in NFS.  Superuser must have
>read access to a file in order to load it into memory, at least in
>theory.  So to execute a file, you have to "copy" it into memory.  If
>Superuser on a machine can read it, how are you going to prevent Joe
>User from having less access than Superuser if the authentication is
>done on the network?

What could be done to make exec-only files more secure in a DOS environment
is to fix up the loader to work remotely.  Currently this is the rough
sequence of what happens when an exec-only file gets run:
  1. authentication code sent to server [code says `I need to access
     program X in order to run it.']
  2. read permission granted
  3. program read into memory and loaded by the local machine's DOS
     loader.
  4. control transferred to program.
Of course the file can be intercepted right at step 3.  However, if the
following was done, we could do much better in the case of .EXE files:
  1. program load request sent to server
  2. server sends requests to workstation for memory allocation
     and places program X into the workstation memory already relocated
     into the correct memory position.  This could be done by a sequence
     of requests from server to workstation and server actions such as:
      a. server reads executable file header and parses it
      b. server requests workstation [SRW] `allocate 345475 bytes,
         making certain that it is no closer to the top of memory than
         45456 bytes and no further than 100003 bytes;  send base
         address back to server.' (the numeric data would be taken from
         the header)
      c. SRW: `prepare to receive 345475 bytes starting at <base-address>'
      d. server sends a program ALREADY RELOCATED for the know base address
         to the workstation. (the relocation could be done on the fly,
         while sending).
      e. SRW: `load in your DOS environment and command line options into
         the PSP'
      f. SRW: `transfer control to <starting-address-of-code>.'
This procedure is useless for fully relocatable programs as the workstation
could disobey request f and simply write the memory data to disk either
at d,e or f.  However if X has relocation data then all the workstation
sees is a relocated version of the program.  This could be dumped to disk,
of course, but it would be almost useless as it would always have to be
loaded at a specific base address.

Since the purpose of exec-only attributes on Novell is to discourage
(impede) the piracy of network-licensed programs by network users,
and most commercial software is now distributed in .EXE files where
relocation info is necessary, this scheme would, I think, help to stop
at least a good part of the piracy.  The disadvantage of this scheme
is, I think obvious: it requires much work on the part of the server.

Anyways, there are a myriad of simple and cheap ways in which the security 
could be made at least harder to beat than now, even without resorting to
a scheme like I described.  My program to beat the Novell network
exec-only security is, in its simplest form, 21 bytes long.  It took
only half an hour to find a workable scheme to beat the security originally.
I am quite sure that the initial development time could easily be raised
to 5 through 10 hours if Novell wanted to, thereby making it more difficult
for JoeHacker to sit there hacking away in a low level debugger without
someone noticing him doing it.  Also individual differences between systems
could be utilized to make certain that the critical memory locations are
different so the JoeHacker1 who does figure things out cannot simply
distribute a canned procedure/program.  (Individual difference are not
enough;  having broken through one version of the network shell, I
could do the other by a simple straightforward procedure in 10 minutes).

Finally I must add that all this work on cracking the security was done
with the full knowledge of my network supervisor, so don't flame me.

pruss@ria.ccs.uwo.ca / ria.uucp