pruss@ria.ccs.uwo.ca (? pruss) (06/07/90)
The Execute-Only attribute in Novell netware seems to be rather poorly implemented. While much care is put into making certain that the attribute is permanent and cannot be revoked by any user (not even supervisor), with a little care and ingenuity any JoeHacker-User with execute priveleges to that file can copy it. In fact I have even been able to write a program that makes it possible for any user to run it and subsequently copy ANY exec-only file. Please note I have distributed neither my program nor specific data on how this is done. 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 am wondering whether any one has hacked netware to make exec-only more secure? pruss@ria.ccs.uwo.ca // pruss@ria.uucp
tr@samadams.princeton.edu (Tom Reingold) (06/08/90)
In article <445@ria.ccs.uwo.ca> pruss@ria.ccs.uwo.ca (? pruss) writes:
$ The Execute-Only attribute in Novell netware seems to be rather
$ poorly implemented. While much care is put into making certain
$ that the attribute is permanent and cannot be revoked by any user
$ (not even supervisor), with a little care and ingenuity any
$ JoeHacker-User with execute priveleges to that file can copy it.
$
$ In fact I have even been able to write a program that makes it possible
$ for any user to run it and subsequently copy ANY exec-only file.
$
$ Please note I have distributed neither my program nor specific data
$ on how this is done.
$
$ 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 am wondering whether any one has hacked netware to make exec-only
$ more secure?
This is probably a "hard" problem to solve. There is no notion of
network security, only security on machines. So once a message gets to
the network, it is assumed to be authoritative.
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?
--
Tom Reingold
tr@samadams.princeton.edu
rutgers!princeton!samadams!tr
201-560-6082pruss@ria.ccs.uwo.ca (? pruss) (06/08/90)
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
cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) (06/09/90)
[This probably won't work.] In article <224@rossignol.Princeton.EDU> (Tom Reingold) writes: >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? Well there are things call privledged ports that can be used sometimes to psuedo-authenticate people, and there is of course "Secure NFS" which uses a public key scheme, and finally there is "Kerberized NFS" which uses Kerberos. The main point being that you are correct in your assertion that presumed authorization by network existence is fatally flawed but _NFS_ per se doesn't know anything about authorization, that is part of the implementation not the design/architecture. UFS doesn't know about authorization either, it counts on the kernel implementation to deny you access when you don't have permission. -- --Chuck McManis Sun Microsystems uucp: {anywhere}!sun!cmcmanis BIX: <none> Internet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "I tell you this parrot is bleeding deceased!"
wesommer@athena.mit.edu (Bill Sommerfeld) (06/09/90)
pruss@ria.ccs.uwo.ca claims that the security of Novell "execute only" could be improved if the fileserver relocated the program before sending it to the client. Now, I'm not really familiar with the subtleties of MS-DOS or Novell, but it seems as if it wouldn't be too hard to reverse engineer this, given a chance to load the program at two or three different base addresses. MP/M-80 -- anyone remember that system? -- generated "page relocatable" files by assembling something at two different base addresses separated by 100H, and then "diff"ing the two binaries. The only way you can have a secure "execute only" facility is if the CPU and program loader are within the "security perimeter"; I get the impression that in normal operation, an MS-DOS system running the client side of the Novell networking package is most definitely outside the perimeter. Anything else, and you're just setting up challenges for crackers.. - Bill -- "The chance of mit-eddie relaying | Bill Sommerfeld at MIT/Athena something before that hyperactive IBM | sommerfeld@mit.edu RT with a thyroid condition gets a hold | of it is pretty slim." |