From: SMTP%"Info-VAX-Request@Mvb.Saic.Com" 15-SEP-1994 16:35:25.35 To: EVERHART CC: Subj: Re: Problems with SYS$GRANTID X-Newsgroups: comp.os.vms Subject: Re: Problems with SYS$GRANTID Message-ID: <1994Sep15.100841@alpha.vitro.com> From: vaxs09@alpha.vitro.com Date: Thu, 15 Sep 1994 14:08:41 GMT Sender: news@vitro.com (USENET News System) Organization: Vitro Corporation Lines: 39 To: Info-VAX@Mvb.Saic.Com X-Gateway-Source-Info: USENET In article , jan@neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes: > I would go with your solution #1. (Which was to have an image installed with CMKRNL privilege and have that image spawn a subprocess to run INSTALL with CMKRNL enabled). There are security risks inherent in using SPAWN from a privileged image with the image's enhanced privileges enabled. DON'T DO IT. It is not safe. There are quite a number of non-obvious loopholes that would allow a non-privileged user to steal the privileges with which such an image has been installed. An attacker could for instance: o Redefine job logical names that the spawned subprocess will use, causing it to run the attacker's images instead of the intended images. o Redefine SYS$SYSTEM (and thereby cause LIB$SPAWN to run the attacker's own image instead of SYS$SYSTEM:LOGINOUT.EXE) o Mess with the mailbox used by SPAWN to initialize the spawned subprocess (stealing the real initialization data and substituting false initialization data). I don't feel too guilty about posting specific techniques because: o The techniques are not hard to invent. o DEC recommends against SPAWNing from privileged images. o Experience shows that folks won't believe that their system is vulnerable until it's demonstrated to them. ("I set the flag that prevents propagation of symbols and logical names, and I don't use INQUIRE. Isn't that enough?") o I've shared this "secret" before. And we all know what happens when you share a secret. John Briggs briggs@vitro.com