Conference noted::hackers_v1

    re: -1
    
    > Captive account's your best bet
    
    Yabbut...
    
    You can still break out of a captive account (we do it all the time).
    
    Re: .0
    
    
    You may be doing something like:
    
    $ read sys$command foo
    $ set host 'foo'
    
    This isn't any better than having the inquire there in the first
    place.
    
    You must filter all input before you do ANY DCL command. The reason
    is that most if not all DCL commands do the same interpretations
    in their own parse trees. For instance, the command
    
    $ Directory @tt:
    
    will yield:
    
    _$ 
    
    and it won't matter if you are in a captive account or not. I strongly
    suspect that's the sort of thing that's happening. 
    
    The main (a little philosophy here) reason one uses a READ SYS$COMMAND
    instead of an INQUIRE is to prevent the  typed input from having
    an immediate effect on the command procedure/environment. However,
    the wise command procedure author must "insulate" all input from
    any dcl command which may use that input. If you issue a READ
    SYS$COMMAND and you don't search for obvious substrings like "F$",
    or "@", or ":=", or "-" or "&", you aren't gaining anything by using
    the READ.
    
    Like I said earlier, just a simple command like PRINT @TT: will
    get you to a dollar sign no matter what kind of account you have.
    If the user types 'F$PID(LOGOUT)' to your READ command, sure, the
    READ won't execute it, but what happens when you do a SET HOST
    'F$PID(LOGOUT)'? 
    
    /pjh
    

    Check the "Guide to VAX/VMS System Security" -- it's one of the
    small 'handbooks'.  Duplicate the beginning of the example captive
    command procedure given there.

    You must justify *every* use of a ' (single quote) before a
    user-provided input.  I think it is sufficient to ensure that
    the symbol itself contains no single quotes.  Something like:

	$read:	read sys$command sym
	$clean:	tmp = sym
	$	sym = sym - "'"
	$	if sym .nes. tmp then goto clean
	$	set host 'sym
	$	...

    If there are qualifiers that must be avoided, remove /s (slashes) too.
    If the input must consist of a particular set of characters, try:

	$read:	read sys$command sym
	$	chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" +-
	$		"abcdefghijklmnopqrstuvwxyz" +-
	$		"_$0123456789"
	$	i = -1
	$10$:	i = i + 1
	$20$:	if i .ge. f$length(sym) then goto 30$
	$	tmp = f$extract(i,1,sym)
	$	if f$locate(tmp,chars) .lt. f$length(chars) then goto 10$
	$	sym = sym - tmp
	$	goto 20$
	$30$:	!
	$	! Any other checks, like checking the symbol length
	$	!
	$	...

	    The 'f$pid(goto)' trick is something I learned from M.
	Gilbert.  The f$pid() lexical makes its argument a symbol
	whose value is a number, a Process ID.  So 'f$pid(goto)'
	creates a "goto" symbol whose value is a number that doesn't
	make any sense as a command.
	    My usual approach for protecting a command procedure is
	to create a "dcl" symbol equal to a space, and putting it in
	front of every command, like this:

		$ dcl = " "
		$ dcl goto TIBET

	That protects it from "goto" symbols.
			<_Jym_>

< Note 289.4 by VAXUUM::DYER "Define `Quality'" >

>>	That protects it from "goto" symbols.

But, Jym.  It doesn't protect you from 'F$PID(DCL)''F$PID(GOTO)' and
such.  If you're really worried about protecting things, and you need
a construction of the form $ VERB 'ARGUMENT', you have you go looking
for apostrophes, @'s and the like.

Sounds like disabling F$PID would be easier.  How do we do that?

-piper

	    Oops!  You're right.  The

			$ dcl = " "

	is something I use to make my command procedures safe from a
	user's symbol definitions; it doesn't help here.
	    However, I have thought up a way to turn f$pid() off.

			$ f$pid = "!"
			$ f$pi = "!"

	You can, of course, replace the "!" with anything else you
	imagine.  If you want to use f$pid() later on in the program,
	just turn off the symbol and then turn it back on.

			$ delete/symbol/local f$pid
			$ really use f$pid(foo)
			$ f$pid = "!"

	    Kludgesville.
			<_Jym_>

    Nice idea, Jym. The point here is that to hack-proof a command
    procedure, you have to remove the ability for something like
    'F$PID(Whatever)' to be executed in the first place. That's why
    I maintain that if you filter your input in the first place you
    won't have problems and you can write cleaner code anyway.
    
    Besides, it's so much more fun to keep 'em guessing, right bill?
    
    /pjh

re .*:  Seems to me that this is a security breach in DCL, there should be a
guaranteed way to execute a GOTO or something and KNOW that you aren't
executing a symbol a clever hacker placed.  I used to use CDC's NOS system and
a similar hack on it was to create a local file with the same name as the
command you wanted to disable.  But if the command in the procedure file was
preceded with a "$", you were GUARANTEED the command interpreter used its own
definition of the command you wished to execute. 

-Mike 

      Re .8
      
      > ... there should be a guaranteed way to execute a GOTO or
      >something and KNOW that you aren't executing a symbol a clever
      >hacker placed.   
      
      There is:  put in $ GOTO = "GOTO" immediately before each GOTO
      statement.


      Dave C.

re .9:  True, but DCL should be set up so that it's TRIVIAL to guarantee a
known command FOO is executed when you say $ FOO.  This is so it would be easy
for marginal programmers to make secure command files, captive accounts, etc.
The system I mentioned (NOS) will do this with the leading special character
"$". (It does not need a leading char in its command files like the DCL "$")
This is similar to the "really" in the previously mentioned sequence

$ really = " "
$ really goto foo

but the special symbol could not be redefined, unlike the above which could be
broken by 'F$PID(really) or something similar. 

-Mike