[comp.os.vms] The latest security bug

art@MITRE.ARPA (Art McClinton) (04/13/88)

SEND is not a DEC VMS command.  Noting your return address I am going to
assume that your VMS system is on bitnet and is probably using the Joiner 
Associates package (Jnet).  SEND is a command within the Jnet product.  It
does require certain privileges to be able to send messages to users that 
are logged in.  It appears to turn on/off privileges as necessary.  It does
not perform the actions the Bucknell students attribute to the command.  VMS
security bugs have been tightly held secrets in recent times.  I do not know
of anyway that you will be able to prove/disprove that any one program caused
a particular problem.

I suggest that you determine what image is invoked by your SEND command.  If
you have a question about it, go to the source of that program.  If the source
is not a reputable one, then determine why you want to keep the program.  

 
     
*
*---Art
*
*Arthur T. McClinton Jr.     ARPA: ART@MITRE.ARPA
*Mitre Corporation MS-Z305   Phone: 703-883-6356
*1820 Dolley Madison Blvd    Internal Mitre: ART@MWVMS or M10319@MWVM
*McLean, Va. 22102           DECUS DCS: MCCLINTON
*

carl@CITHEX.CALTECH.EDU (Carl J Lydick) (04/14/88)

 > My questions is this: could anyone tell me ("yes" or "no" would be fine)
 > whether the latest bug (the one just patched) involved the SEND command?
 > I want to know because I'd like to be able to argue for the return of
 > SEND privileges, but I first need to know if there is a reason other
 > than harassment for their suspension. If the patch was received here and
 > installed, there should be no exceptionally strong argument against the
 > return of privileges.

Since the bugfix is being distributed by DEC, and not by Joiner Associates,
the answer to your question is obviously NO.  SEND is NOT a part of vanilla
VMS.  It is part of JNET.  A description of the patches follows:

  1) $VWS (miscellaneous fix)

    ! $VWS.VUG
    !
    !	ECO01	DMC				15-Feb-1988
    !	MODULE: VWS
    !		Check for the existence of two VWS images.  If they
    !		exist, ANALYZE to determine the VWS version from which
    !		they were built.  If they are not V3.1 or V3.2 images,
    !		delete the .VUI and .EXE files which will otherwise
    !		be invoked later to provide the updated images.
    !


  2) DBGSSISHR (new image)

    ! DBGSSISHR.EXE
    !
    !	ECO01	KNM0001		17-Feb-1988
    !		MODULE: DBGSSISHR
    !		Update the image with some fixes.
    !


  3) SYS (patch image)

    ! SYS.EXE
    !
    !
    ! Define the following symbols so that the patches can be reapplied.


  4) TTDRIVER (miscellaneous fix)

    ! TTDRIVER.VUG
    !
    !	ECO01	FAK	18-FEB-1988
    !		MODULE: TTDRIVER
    !		Set up to use the appropriate TTDRIVER file based on
    !		which version of VMS is running.


  5) TTDRIVER (new image)

    ! TTDRIVER.EXE
    !
    !	FAK	16-Feb-1988
    ! 
    !	New TTDRIVER image.  This TTDRIVER has changes for VWS, 
    !	8NN console problems, and some miscellaneous fixes.
    !