Conference vaxaxp::vmsnotes

   There have been several discussions of this here and in in other notes
   conferences -- the $ADD_HOLDER service is itself implemented in a loadable
   system service, and the interlock you are seeing is intended to prevent a
   user-written system service from being compromised, and the $ADD_HOLDER
   is triggering the problem.


:  I'm not concerned about the SYS$PUBLIC_VECTORS entries as
:  they're in a global section somewhere, so I assume they're safe (?).

   These are at the top end of the protected area of process P1 space,
   and these vectors cannot be diverted by any (non-privileged, non-
   inner-mode) alterations. (These vectors are not in a global section
   -- they are normally a direct remapping of the old location of the
   system service vectors; of the bottom end of S0 space.)

:  The
:  only remaining unprotected entity appears to be the ". BLANK ." PSECT which
:  is empty. Will the image be safe from malicious or accidental abuse?

   If there is nothing in the PSECT and no references to it, it is safe.

:  Can enyone explain why using /PROTECT causes the outbound call error?

   See below.

   Also see VAXAXP::NOTES$ARCHIVE:ALPHANOTES_V1 notes 640.0 and 1908.0,
   among other notes.



UNIQUE_IDENTIFIER: 0094CC1A-ACDF2BE0-1C01E7
TITLE: SYSTEMFNOSHRIMG Error When A UserWritten System Service Is Called
  EDITORIAL_REVIEWED,FIELD_READABLE,NOFLASH,TECHNICAL_REVIEWED,READY)
Copyright (c) Digital Equipment Corporation 1987, 1991. All rights reserved

COMPONENT:  User-Written System Services                  OP/SYS:  VMS

SOURCE:     Digital Customer Support Center

VERSION INFORMATION:

     Symptoms Identified On:  VMS, All Versions


SYMPTOM:

The following errors are displayed when a user-written system service
is called from a program:

     %DCL-W-ACTIMAGE, error activating image USS
     -CLI-E-IMGNAME, image file DISK:[SYSn.][SYSLIB]USS.EXE
     -SYSTEM-F-NOSHRIMG, privileged shareable image cannot have
                         outbound calls

NOTE:  More information on user-written system services may be
       found in Appendix A of the "Introduction to VMS System
       Services", April 1988, (AA-LA68A-TE).


ANALYSIS:

This error indicates that a user-written system service tried to call
a routine that is in a shareable image.  There are some VMS-supplied
system services that, when called from a user-written system service,
ALWAYS generate the NOSHRIMG error.  They are LOADABLE system services
and found in the shareable image SYS$SHARE:SECURESHR.EXE.  The
following services are of this type:

     SYS$GETUAI
     SYS$SETUAI
     SYS$PARSE_ACL
     SYS$FORMAT_ACL
     SYS$CHANGE_ACL
     SYS$CHECK_ACCESS
     SYS$FIND_HELD
     SYS$ADD_HOLDER
     SYS$ADD_IDENT
     SYS$CREATE_RDB
     SYS$FIND_HOLDER
     SYS$MOD_HOLDER
     SYS$MOD_IDENT
     SYS$REM_HOLDER
     SYS$REM_IDENT

In most cases, linking the user-written system service with the
'/NOSYSSHR' qualifier and not specifying any shareable images at link
time, prevents the error from occurring at run-time.  However, this is
not the case if any of the above system services are called, since
these services are not available in object format and must execute
from the shareable image.


SOLUTION:

When the above system services must be called, the only alternative is
to create an executable program (not a user-written system service) to
call the VMS system service, and then use the INSTALL Utility to
install the executable image with the privileges that are required.
\
\
\ CONTRIBUTOR(S):
\
\      Technical:
\           Mark Misfeldt (151632) of DSNlink Engineering
\           Steve St.Clair (173845) of SPACE
\
\      Editorial:
\           Tim Gorton (120681) of CSSE
\           Steve St.Clair (173845) of SPACE
\
\\ LINK INSTAL PROG/SEC 151632 SPACE 173845 GENERIC %001 PROD=VMS SPD=25.01
\\ OS=VMS GRP=VMS CAT=OPSYS STATUS=CURRENT DB=V5_VMS

    re .*
    
    Why does it "work" on VAX and not on Alpha?
    
    
    If you get really desperate, you could probably put the call to
    $ADD_HOLDER in a separate process. The necessary system services to
    create a new process and communicate with it presumably are usable from
    a UWSS.

  re .1:

    Sorry, I'm still confused. On the one hand it seems I've protected all
  necessary PSECTs and, as you say, the "unprotected" SYS$PUBLIC_VECTORS are
  secure against non-privileged alterations, so the image *should* be secure.
  On the other hand, the STARS article says 

"When the above system services must be called, the only alternative is
to create an executable program (not a user-written system service) to
call the VMS system service, and then use the INSTALL Utility to
install the executable image with the privileges that are required."

  I've read the ALPHANOTES_V1 references, they don't really clarify the
  situation either. It seems to me that there *may* be a secure alternative
  when calling these services, as outlined in .0, provided it's possible to
  make all relevant PSECTs protected. Can anyone point to any insecurities
  in an image linked in this manner?

 re .2: Why does it "work" on VAX and not on Alpha?

  I'm not so sure that it does "work" on VAX, but if it does, I suspect it's
  because the service is a "real" system service, rather than in SECURESHRP.

						John Gillings, Sydney CSC

re .3
    
>  I'm not so sure that it does "work" on VAX, but if it does, I suspect it's
>  because the service is a "real" system service, rather than in SECURESHRP.

Nope. The security services are all in a shareable image on VAX (as on Alpha).
    
    Besides ensuring that all PSECTs that need to be are protected, one
    needs to address the more fundamental question...where is the callout
    going? Is there any protection against the UWSS calling hacker supplied
    code?

  re .4:

>.where is the callout
>    going? Is there any protection against the UWSS calling hacker supplied
>    code?

    Good question. Since the only "dangerous" calls are to SECURESHRP, I
  created a "clone" (reconstruct symbol vector from ANALYZE/IMAGE output and
  populate with routines which return a charateristic status code). Next, I
  attempted to hijack the calls to SECURESHRP by defining a logical name
  pointing to my fake image. In the case of an image structure
  MAIN->UWSS->SECURESHRP my SUPERVISOR/LNM$PROCESS_TABLE logical name is
  ignored. That's because the image is activated from "under" the UWSS so
  parinoid mode is in effect.

    Next, I tried adding an explicit reference to SECURESHRP from my main
  program. That way SECURESHRP would be activated *before* the UWSS, so I
  may be able to bypass parinoid mode: 

$ run TEST_ADD_HOLDER3
%DCL-W-ACTIMAGE, error activating image UWSS2
-CLI-E-IMGNAME, image file DPA2:[Q50960]UWSS2.EXE
-SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged imag

  So, the image activator is smart enough to ignore the untrusted shareable
  image (pity the error message isn't a bit clearer about which file is
  at fault though ;-). As a sanity check, I tried INSTALLing my fake
  SECURESHRP:

$ install add secureshrp
$ run TEST_ADD_HOLDER3
$ show sym $status
  $STATUS == "%X00000065"

  which is my magic number for $ADD_HOLDER, so I have managed to hijack the
  call from the UWSS, but only by using CMKRNL privilege.

  In summary, all relevant image sections in the UWSS are protected against
  outer mode access, nor is it possible to subvert the outbound calls without 
  privilege. The UWSS is therefore safe (within the bounds of what the
  programmer explicitly allows). 

  I still don't understand why this image gets past the image activator
  without the NOSHRIMG error while the one linked /PROTECT does not. Have
  I really found a "safe" loophole to allow outbound calls, or have I missed
  some obvious security hole? (ie: leave at least one, non-critical image
  section unprotected).
						John Gillings, Sydney CSC

  A bit more investigation...

  It appears the trigger for the NOSHRIMG error is EISD$V_PROTECT=1 in the
  image section descriptor for the section containing the fixup vector for
  the UWSS. If the flag is 0, the image is activated.

  On VAX the fixup vector actually holds the runtime addresses of referenced
  routines, which could potentially be hacked, thereby trapping the outbound
  calls. However, on Alpha, the fixup section appears to do nothing after
  image activation, and, although the section is indeed user mode writeable,
  there doesn't seem to be anything which could be changed which would affect
  run time behaviour. So, I still can't find a way to subvert the UWSS.

						John Gillings, Sydney CSC