jimf@pro-gateway.cts.com (Jim Ford, Co-SysOp) (12/25/90)
salter> How does one prevent an application from shelling to DOS? What do you mean how do you PREVENT it??? It should be that you only shell to DOS when you tell the application to do so??? Maybe I am just stupid or confused but what do you mean? =============================================================================== ProLine: jimf@pro-gateway Internet: jimf@pro-gateway.cts.com UUCP: crash!pro-gateway!jimf ARPA: crash!pro-gateway!jimf@nosc.mil BITNET: jimf%pro-gateway.cts.com@nosc.mil ====================Pro-Gateway 214/644-5113 3/12/2400 baud====================
craig@sa2.hgc.edu (craig chaiken) (12/26/90)
In article <1990Dec24.012958.9228@magnus.ircc.ohio-state.edu> salter@magnus.ircc.ohio-state.edu (John E Salter) writes: > >How does one prevent an application from shelling to DOS? >Particuarly applications running on a novell network >which is started from a menu system. Thank you. > The following is a list of ways to prevent an application from shelling out to DOS: 1) Rename COMMAND.COM just prior to executing the application, and restore it upon exit from the application. (Dangerous if the machine crashes while COMMAND.COM is renamed). 2) Fill up RAM with so many TSRs that insufficient RAM is available for shelling to DOS (I like this option). 3) Patch the application, so as not to offer the DOS shell option. 4) Write a TSR to capture the INT 21H EXEC function (AH=4BH). Ignor any requests to run COMMAND.COM, and execute all other requests. (Actually, not that hard to program, but certainly not for beginners). 5) If you run SHARE.EXE, you might be able to lock the COMMAND.COM file as WRITE-ONLY (I've never tried this). You would have to do this from a TSR, in order to keep the file locked, though. I hope at least one of these methods proves to be useful. Craig Chaiken (Author of "Blueprint of a LAN", and soon to be released, "Beyond Blueprint of a LAN") craig@mstr.hgc.edu
abrams@cs.columbia.edu (Steven Abrams) (12/26/90)
In article <1990Dec25.233917.15240@mstr.hgc.edu> craig@sa2.hgc.edu (craig chaiken) writes: >The following is a list of ways to prevent an application from shelling out to >DOS: >1) Rename COMMAND.COM just prior to executing the application, and restore > it upon exit from the application. (Dangerous if the machine crashes > while COMMAND.COM is renamed). This may be the best bet; even better, is to permanently rename COMMAND.COM to something else and use the SHELL= in config.sys to allow the system to boot with the "other" COMMAND.COM. To be doubly safe, reset COMSPEC environment variable to some nonexistent program before running the application to prevent it from checking the env. for the location of COMMAND.COM. The downside of this approach is that if, when the application exits, it has used enough RAM to walk on the transient portion of COMMAND.COM, when DOS checks the environment to find out where to load COMMAND.COM, it will fail with "Please insert disk with COMMAND.COM in Drive C: and press any key..." or something dumb like this. >4) Write a TSR to capture the INT 21H EXEC function (AH=4BH). Ignor any > requests to run COMMAND.COM, and execute all other requests. (Actually, > not that hard to program, but certainly not for beginners). I think this is the best option of all, but, as you said, not for the fainthearted. ~~~Steve -- /************************************************* * *Steven Abrams abrams@cs.columbia.edu * **************************************************/ #include <std/dumquote.h> #include <std/disclaimer.h>
james@bigtex.cactus.org (James Van Artsdalen) (12/26/90)
In <1990Dec24.012958.9228@magnus.ircc.ohio-state.edu>, salter@magnus.ircc.ohio-state.edu (John E Salter) wrote: > How does one prevent an application from shelling to DOS? > Particuarly applications running on a novell network > which is started from a menu system. Thank you. You could intercept the INT21 EXEC function call. Be careful not to gratuitously inhibit all COMMAND.COM execs. Various programs will legitimately use a shell() type function in order to run programs without regard to whether they are binary or batch files. Try to detect the cases you want based on the arguments to COMMAND.COM. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
cantie@acsu.buffalo.edu (bruce n cantie) (12/26/90)
In article <1990Dec25.024222.13265@xrtll.uucp> silver@xrtll.UUCP (Hi Ho Silver) writes: >In article <1990Dec24.012958.9228@magnus.ircc.ohio-state.edu> salter@magnus.ircc.ohio-state.edu (John E Salter) writes: >$How does one prevent an application from shelling to DOS? > > Well, before invoking it, you could set the COMSPEC environment variable >to point to a program which simply returns, and reset it afterwards. There >may well be other ways ... Another 'easy' way is to simply do SET COMSPEC= before invoking the program. Then reset the COMSPEC back to the valid COMMAND.COM. In our case the DOS directory on the server is always mapped to Y:, so we do: SET COMSPEC= PROGRAM SET COMSPEC=Y:COMMAND.COM You might have to work things a little different if you ues boot disks or hard drives in the workstations (we have boot proms in the 3COM 501 and 503 cards condifured for packet drivers to use telnet/ftp). >-- > __ __ _ | ...!nexus.yorku.edu!xrtll!silver | always >(__ | | | | |_ |_) >----------------------------------< searching > __) | |_ \/ |__ | \ | if you don't like my posts, type | for >_____________________/ find / -print|xargs cat|compress | SNTF -- ---------------------------------------------------------------------------- Bruce Cantie Internet: cantie@cs.Buffalo.EDU | I speak only for me, LAN Systems BITNET: LSBRUCE@UBVM.BITNET | U.B. has nothing to 301A Computing Center BITNET: LSBRUCE@UBVMS.BITNET | do with it.
sweh@tharr.UUCP (Stephen Harris) (12/26/90)
In article <ABRAMS.90Dec25210447@division.cs.columbia.edu> abrams@cs.columbia.edu (Steven Abrams) writes: !In article <1990Dec25.233917.15240@mstr.hgc.edu> craig@sa2.hgc.edu !(craig chaiken) writes: !>The following is a list of ways to prevent an application from shelling out to !>DOS: ! !>1) Rename COMMAND.COM just prior to executing the application, and restore !> it upon exit from the application. (Dangerous if the machine crashes !> while COMMAND.COM is renamed). ! !This may be the best bet; even better, is to permanently rename !COMMAND.COM to something else and use the SHELL= in config.sys to !allow the system to boot with the "other" COMMAND.COM. To be doubly !safe, reset COMSPEC environment variable to some nonexistent program !before running the application to prevent it from checking the env. !for the location of COMMAND.COM. The downside of this approach is !that if, when the application exits, it has used enough RAM to walk on !the transient portion of COMMAND.COM, when DOS checks the environment !to find out where to load COMMAND.COM, it will fail with "Please !insert disk with COMMAND.COM in Drive C: and press any key..." or !something dumb like this. ! What I would possibly do is have COMMAND.COM in my c:\DOS directory and have SHELL=...statement in my config.sys file, and then write a small C program which resets COMSPEC to either a non-existent file (so shell fails) or to a specific program which prints "No shell allowed". Then the C program can call the original program (by SPAWN, not EXEC) and finally restore COMSPEC back to its original. This will take up some extra memory (maybe 4k!) an also not suffer from worrying whether transient portion of memory gets overwritten. !>4) Write a TSR to capture the INT 21H EXEC function (AH=4BH). Ignor any !> requests to run COMMAND.COM, and execute all other requests. (Actually, !> not that hard to program, but certainly not for beginners). ! !I think this is the best option of all, but, as you said, not for the !fainthearted. Too complicated - it *would* work but is surely unnecessary. -- Stephen Harris Disclaimer: me have an opinion? | Email: ..!ukc!axion!tharr!sweh What an idea! | sweh%tharr.uucp@uk.co.bt.axion Wanted: humour transplant | tharr!sweh@uk.ac.ukc <-- tharr *free* public access to Usenet in the UK 0234 261804 -->
abrams@cs.columbia.edu (Steven Abrams) (12/27/90)
There's another problem with eliminating access to COMMAND.COM to prevent shelling out. Many programs not only allow you to shell out to DOS, but also allow you to run any program. If we just change COMSPEC so that the shell fails, it isn't too difficult for a user to, instead, run COMMAND.COM as a plain program, either from the root directory, the C:\DOS directory, or the network directory. If you want to make the system impervious to all of these types of things, there are only a few options (none of which are perfect). 1) Never use COMMAND.COM as such; always rename it to something else. This eliminates the RUN COMMAND.COM approach. 2) In order for DOS to boot, you need a SHELL= command now. 3) Before running the application, reset COMSPEC to either a bogus file or, as someone else suggested, to a short program that prints "No shell allowed" and exits. This prevents the "normal" SHELL option from working. This will fail if the application is big enough to require a reloading of COMMAND.COM on exit, as I noted earlier. The big problem is that there is no way to prevent the user from looking at the COMSPEC variable BEFORE starting the application. Then, they could find out where the real shell is and run it as a normal program. Latching onto the exec interrupt and being really careful about what calls you allow and what calls you don't might be the only guaranteed method of disabling the shell out option without crippling the system. ~~~Steve -- /************************************************* * *Steven Abrams abrams@cs.columbia.edu * **************************************************/ #include <std/dumquote.h> #include <std/disclaimer.h>
silver@xrtll.uucp (Hi Ho Silver) (12/29/90)
In article <ABRAMS.90Dec26142244@division.cs.columbia.edu> abrams@cs.columbia.edu (Steven Abrams) writes:
$The big problem is that there is no way to prevent the user from
$looking at the COMSPEC variable BEFORE starting the application.
The original poster asked for how to do it from a menu program; depending
on the menu software, it may indeed be possible to prevent the user from
looking at COMSPEC.
--
__ __ _ | ...!nexus.yorku.edu!xrtll!silver | always
(__ | | | | |_ |_) >----------------------------------< searching
__) | |_ \/ |__ | \ | if you don't like my posts, type | for
_____________________/ find / -print|xargs cat|compress | SNTF