home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18056 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  3.7 KB

  1. Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!UH01.Colorado.EDU!DWING
  2. From: DWING@UH01.Colorado.EDU ("would rather be skiing ...")
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Failures in system security.
  5. Message-ID: <01GR7RHREZCI00O2ZI@VAXF.COLORADO.EDU>
  6. Date: 16 Nov 92 17:16:33 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 63
  11.  
  12. Brendan Welch, welchb@woods.ulowell.edu, writes:
  13.  
  14. >        Does anyone have a program which monitors the phone object (29) to
  15. >catch "blast" programs.  A blast program is defined as one which allows
  16. >the user to make an unidentified message appear on another user's
  17. >screen (in real time).
  18. >        We have been having a lot of trouble with such users.  (I should
  19. >complain?  They typically tell a pretty girl to report to the computer room.)
  20. >
  21. >        More generally, for an operating system (VMS) which is considered
  22. >so secure, the blast message is a poke in the eye.  I hear that DEC's
  23. >answer will be to simply remove the phone utility.
  24.  
  25. The two problems you mention are related to VMS's trusting the underlying 
  26. network.
  27.  
  28. >        But a perhaps worse hole is the "fake mail" message, i.e., it uses
  29. >the mail utility (object 27), but the name of the sender is replaced with a
  30. >fake one.  [If I receive a message that says for me to report to the president's
  31. >office at 7am, and act upon it, that is not a secure system.]  It seems to me
  32. >that DEC could easily change mail to check for this switch, but maybe I do
  33. >not understand about who is really accessing the object (is it the privileged
  34. >system or is it the unprivileged user?).  
  35.  
  36. Normally, mail (on the local node) access the mail object on the remote node
  37. on behalf of the local user.  Mail (on the local node) fills in the appropriate
  38. from/to fields.  A user wishing to send a fake mail message need only connect
  39. to the mail object on the remote node (the "remote node" could be the local
  40. node if you specify 0::, nodename::) and fill in what they think should be
  41. the "appropriate" fields.  The problem is that the local system allows a 
  42. non-privileged user to connect to the mail object on a remote node (this can
  43. be restricted in VMS V5.5-2 to require that only privileged users or images
  44. can connect to the mail object on a remote node).
  45.  
  46. >And maybe if DEC changes the mail
  47. >utility, the user will simply be able to supply an alternate one, for
  48. >reasons unclear to me.
  49. >        Does anyone have a program to check for this problem also?
  50.  
  51. The MAIL problem is "solved" (note the quotes, and see the last paragraph) in 
  52. VMS V5.5-2.  The PHONE problem could be circumvented by taking away NETMBX 
  53. from all your users and Installing those images that need NETMBX (MAIL.EXE, 
  54. RTPAD.EXE) with the NETMBX privilege.
  55.  
  56. An idea to secure PHONE (similar to VMS V5.5-2's method to secure MAIL):
  57.  
  58. I just experimented with settting the PHONE object to require SYSNAM for 
  59. outgoing connections (PHONE.EXE is installed with SYSNAM, among others), for
  60. outgoing connections (just like VMS V5.5-2's release notes regarding Mail)
  61. by performing the NCP command:  SET OBJECT PHONE OUTGOING PRIV SYSNAM.  This
  62. seemed to prevent non-privileged users from using the PHONE object to 
  63. connect to remote systems (or the local (0::) node).  VMS V5.5-1.  Could
  64. someone else verify this?
  65.  
  66. If this does "secure" the PHONE object, it is the same as the VMS V5.5-2
  67. "secure" of MAIL -- it doesn't prevent your system from receiving illegitimate 
  68. messages from somewhere else on the DECnet network, it just prevents 
  69. non-privileged users from sending illegitimate messages from your node to
  70. other nodes.
  71.  
  72. -Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11)
  73.  Systems Administrator, University Hospital, Denver
  74.  
  75.