Conference noted::hackers_v1

290.0. "Bad Secure DCL Procedures" by FROST::HARRIMAN (ACK Phfft!) Mon Aug 18 1986 15:08

    The last topic concerned SECURING a command procedure. The whole
    discussion is reminding me of the problems I have recently had concerning
    command procedures, i.e. the problems of bad design and the ingenuity
    of good hackers. 
    
    The following story relates my problems which are in no way
    all-encompassing. 
    
    Well, I had the dubious responsibility to help secure a collection
    of command procedures that make up the user interface for our financial
    and manufacturing system here at BTO (MAXCIM to those who know).
    
    The reasons that the I.S. department wanted security on the system
    are rather obvious considering the nature of the information on
    the system. However, many members of the plant community did not
    agree with the philosophy about why information needed to be kept
    on the system. To compound the problems, a lack of effective planning
    on the part of the systems technical support and the programmer
    who worked on the original interface made for many security holes.
    To defend (only slightly) the people who did this, they actually
    did not expect any in-plant security problems. However, this didn't
    stop security problems from happening.
    
    When I started looking into the problem, the "unbreakable" command
    procedures had been in place for about a week and the DBA asked
    me to see if I could figure out how the engineers had (apparently)
    broken out of the user interface (back to the dollar sign)... I
    was not working on this part of the system at the time, but I went
    looking and found a whole lot of problems. I relate these as a service
    to any of you who may have the same "problem".
    
    First, all of the command procedures are "menu driven", i.e. the
    user is supposed to type numbers to get selections on the menu.
    The selections are serviced in a DCL procedure which calls other
    DCL procedures which do whatever the options are. Of course, the
    first thing I noticed was that every single input statement was
    an INQUIRE. This, obviously, was a hole (gross understatement) so
    I started working on this. In addition, I noticed some more esoteric
    ways to break out of the menu. For instance, three of the options
    on the main menu concern printing/typing of reports, logs and command
    files. (users are not allowed to COPY or RENAME things). The validation
    function was basically an INQUIRE followed by a DIRECTORY of the
    input, then either a PRINT or a TYPE command. Obviously, it was
    possible to just try to type @TT: and get a dollar sign there too.
    
    In addition, it turned out (though nobody figured it out until after
    I fixed it) that the command sequence would also have allowed a
    diligent hacker to have tried to type the report named
    *.LOG/OUTPUT=LOGIN.COM which would have barfed on the second (type
    or print) command but would have overwritten the LOGIN.COM in the
    user's directory. This was, of course, solved by removing the LOGIN.COM
    from the user's directory and placing it in a common area, owned
    by the system.
    
    More neat things were found in the batch procedures section where
    a program was called to verify passwords to MAXCIM. These were then
    passed as parameters to the submitted batch programs, so any hacker
    who did break out and did a SHOW QUEUE/FULL/ALL would get other
    people's passwords (passed as parameters)!
    
    By the time I waded through all of these silly things I figured
    I probably missed something somewhere, and I was not dealing with
    ordinary probers either (hats off to them by this point). So I went
    one step further. Instead of just logging off a user if I detected
    a security break attempt (if F$LOCATE("F$",input)...) I would go
    to a "gotcha" routine, which would mail a note to the DB administrator
    with a subject saying where the break was detected. This served
    two purposes. The hackers knew what was happening by typing control-T
    when the menu suddenly paused after an attempt, and the DBA got
    notes fingering the perpetrators at the time they were attempting
    things. Score one for the white hats...
    
    Other holes which I found myself (i.e. before other people did,
    I think) were SUBMIT/REMOTE allowing users to submit DCL procedures
    copied into the DECNET account under their own usernames, network
    access in general (we had to entirely remove the TASK object, something
    that was not done originally), and one really stupid one which was
    caused by I.S. itself. 
    
    I.S. updated the command procedures (not I but someone else had
    updated them), copied the updated command procedure into the master
    directory, and then PURGED the master directory. Unfortunately,
    users were logged in and had mapped the original procedure in their
    space, although they were in an image at the time of the purge.
    When the image exited, they got an Invalid Internal Identifier error
    and voila'! they were at the dollar sign. Some re-education was
    warranted there.
    
    We also ended up setting the following flags in all of the user
    UAF records: DISMAIL, DISCTLY, and the one that shuts off SET HOST
    (I forgot what that one's called). This fixed a few more problems
    around DECnet access.
    
    
    Anyway, since I finished working on most of the known holes, I have
    been able to make peace with the perpetrators mostly just by
    identifying them, and since I can;t break the menus anymore I am
    beginning to trust them a bit more (I still don't trust them all
    the way). We are trying to educate the user community as to why
    we need this sort of control in that particular system, however,
    there are still attempts by various and sundry unscrupulous characters.
    
    The moral, if it can be called that, to this story is that trying
    to restrict some users to certain functions is easy as long as you
    really restrict the users a lot. As soon as the user can write things
    into their directories, more insulation is needed. If you do anything
    that uses a standard VMS command, you have to make DAMN sure it cannot
    be broken. The best way to exercise something like this is to set
    the hackers loose on it. I am reminded of the earlier command
    procedures that were touted as "unbreakable" and were so full of
    holes they were silly. The Titanic was "unsinkable" and look where
    it is... Insulating the user from the environment is a two-edged
    sword - you may not be able to fully insulate a user from the system,
    and if you do, they may not be able to get their job done. 
    
    Remember that I had to fix a problem long after the decisions had
    been made to commit the system to this type of security scheme.
    If I could have had more say in the first place, I would never have
    made a menu driven interface (I would have lobotomized DCL instead).
    However, anyone with the same sort of problem facing them would
    do really well to heed these warnings. If you are planning on writing
    command procedures, don't make them do too much, and if they do
    too much, they can and will probably be broken.
    
    
    
    	"Nothing is EVER foolproof because fools are SO ingenious!"
    
                                                   
    /pjh_who_should_have_known_better_in_the_first_place...
    

    I thought that secure DCL procedures were generally impossible,
    except for the trivial case.   
    
    For a truly secure procedure, don't you need to run an image
    that parses the user's input and either does the right thing
    or sets up some controled varibles later used in the procedure?
    [I guess it would be possible to write your own parse in
    DCL -- I hadn't thought of that.]
    
    On security, I heard it said that the worse way to secure
    a system is via trial and error.   If you can't prove to yourself
    that it is secure, it isn't.
    
  	KC

    	It is very difficult to write a DCL procedure that is non-trivial
    and secure. Also, if it is written in DCL *everyone* thinks both
    that they understand it, and that they can improve it.
    
    	If you want a secure captive account then the command file should
    look something like
    
    $ run image
    $ logout
    
    	Then you can get user commands and crunch every character in
    them safely, or use FMS for menus and let it validate that you only
    get a numeric reply. After this it is not too difficult to design
    the application so that it is fairly secure. You still have to ensure
    that the account is set up correctly, and that any files created
    do not cause name conflicts (put a unique suffix on them). And you
    now have the major advantages that not just anyone thinks that they
    can "just add an extra little feature", and even if they do they
    are less likely to add an extra little security loophole than if
    they did it in DCL.

    re: .1
    
    	I agree on both counts. I have maintained here that nothing
    written in DCL can ever be fully secure. However, it can be made
    reasonably hack-resistant (reasonably being a very relative term
    :-) even if you can never be sure.
    
    re: .2
>        	It is very difficult to write a DCL procedure that is
>    non-trivial and secure. Also, if it is written in DCL *everyone*
>    thinks both that they understand it, and that they can improve it.
                 
    Very true. That's why if I had my way I would just lobotomize DCL
    so people couldn't do anything I didn't want them to do. Then you
    wouldn't need captive accounts either. Ever tried to sell that idea
    to managers who don't understand what you are doing in the first
    place? The point I am trying to make clear is that a vanilla DCL
    is not necessarily a good idea on some systems. My managers recognize
    that. The solution inevitably (this has happened many times before)
    is to use the "captive account" approach. I am NOT defending myself,
    my managers, or DCL command procedures. However, the choices that
    were available were ACMS (too piggy for the cluster), a menu-driven
    application (beyond that particular programmer's ability, so he
    said no), and a set of DCL command procedures (chosen because the
    programming staff "knew" DCL and could write procedures quickly).
    This is the "have your cake and eat it too" paradigm - I didn't
    like the decision, but I had to fix it anyway (ex post facto). Also,
    one must recognize that even an application program can be broken,
    and sometimes the results are worse. I agree, an image is much much
    more secure than DCL could ever hope to be (if it is designed
    correctly) but an image is more costly to develop. 
    
    /pjh
    
    

    	re: .3
    
    	Unfortunately, lobotomising DCL is not too satisfactory either.
    The only supported way is to supply a restricted set of DCL tables.
    This does not stop me doing the following :
    
    
    $ x = "$tavisc::sys$system:rtpad"
    $ x
    Node name: idefix
    
    Username:
    
    In doing the above I have used nothing from DCLTABLES, so anything
    you did to that would not stop me from setting host. (The reason
    for the "tavisc" is that I need a V3.7 rtpad. The X4.5 one I have
    on pastis does not like to work this way).
    
    		Dave

    Not really... Notice you had to resort to going off of your system
    to get an image that worked? On a really secure system, nobody would
    need NETMBX (nothing gets copied off)... so that wouldn't work.
    
    Also, deleting entities like MCR and RUN make life much harder.
    For all DCL utilities (I can't find any exceptions) if the user
    tries:
    
    Dir == "$DIRECTORY"
    
    the user gets blown off with
    
    %Error parsing KJHSKJHS.
    Specified entity not found in command tables
    
    And for non-DCL utilities like MAIL, all that is needed is judicious
    use of ACL entries. I know it gets messy, but any dedicated system
    which really needs this level of security has relatively few
    applications running on it anyway. I mean, really, we're not talking
    about your basic OA system here.
    
    /pjh
    

	    There will always be utilities and programs that don't die
	with CLI errors if you run them like that.
			<_Jym_>