From: SMTP%"Ned.Freed@innosoft.com" 23-MAY-1996 12:49:16.84 To: everhart@star.zko.dec.com CC: Ned.Freed@innosoft.com Subj: Re: Mail Bounce > Haven't looked at deliver in ages, but can you elaborate on what was done > to mail that opens security issues with it? DELIVER depends on VMS MAIL being installed with privileges, specifically SYSPRV and CMKRNL. (So do a bunch of other foreign protocol interfaces, e.g. the one in JNET.) VMS MAIL used to support being installed with privileges -- it simply disabled them and let whatever foreign protocol interface needed them reenable them as necessary. Pretty normal stuff. With the advent of VMS 7.0, however, VMS MAIL has been rewritten in C and the privilege disabling code has been removed. This means that when you install VMS MAIL with privileges you end up with a major security hole. DEC said during the VMS 7.0 field test that they would continue to provide the old BLISS version of VMS MAIL unchanged for people who needed it. We grumbled but felt that this was an acceptable, albeit unpleasant, state of affairs. But this was only true up to the actual release -- at which point the privilege handling code in the BLISS version was also removed, leaving no user agent technology on VMS capable of using DELIVER safely. We have complained about all this several times but nobody at Digital seems to be listening. We issued a revision of PMDF that removes standalone DELIVER right away as a result, and we have also reported the security exposure to CERT. The net result is that DELIVER can no longer work without causing a major security exposure. Now, DELIVER could be rewritten so as to operate as a protected shareable image running in exec mode. However, such images are extremely difficult to write, they can crash your system if they misbehave, and there is ample evidence that getting the security handling in them right is a major undertaking in and of itself. And since we've been using a much-enhanced version of DELIVER that operates from within PMDF for many years now that gets its security from operating inside of a protected environment rather than running in user context, developing a protected version of the old DELIVER is something we're just not interested in doing. In effect DEC, having screwed their customers rather soundly, has actually helped us: They have just provided people with considerable motivation to purchase PMDF so as to obtain the enhanced DELIVER functionality it provides. That's nice for us, I guess, but I really worry about all the sites out there that are using DELIVER that will never get told about this or notice it and will end up totally compromised as a result. Ned ================== RFC 822 Headers ================== Return-Path: Ned.Freed@innosoft.com Received: by dimond.zko.dec.com (UCX V4.0-10B, OpenVMS V6.2 VAX); Thu, 23 May 1996 12:49:13 -0400 Received: from THOR.INNOSOFT.COM by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id MAA13549; Thu, 23 May 1996 12:43:58 -0400 (EDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I51FCH2BYO9QUQU0@INNOSOFT.COM>; Thu, 23 May 1996 09:42:55 -0700 (PDT) Date: Thu, 23 May 1996 09:28:34 -0700 (PDT) From: Ned Freed Subject: Re: Mail Bounce In-reply-to: "Your message dated Thu, 23 May 1996 09:36:29 -0400" <96052309362919@star.zko.dec.com> To: everhart@star.zko.dec.com Cc: Ned.Freed@innosoft.com Message-id: <01I51H5KOK349QUQU0@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT