[comp.os.vms] Security patch

KVC@ENGVAX.SCG.HAC.COM.UUCP (05/27/87)

> Now, the question. Has anyone else applied the above patch? If so, did
> you find that programs that use the patched routines need to be relinked?
> Better yet, did you run into any problems at all?

I installed the security patch last week during production and have not
had to relink anything.  I just reinstalled the image.  No problems.
My test program that demonstrates the hole now fails nicely.

        /Kevin Carosso                 kvc%engvax@oberon.usc.edu
         Hughes Aircraft Co.           kvc@engvax.scg.hac.com

AWalker@RED.RUTGERS.EDU.UUCP (06/08/87)

Why doesn't someone just *post* the Patch input file to infovax, if DEC is
dragging their heels so?  If there are explanatory comments detailing the
security hole in the header of this, you could even strip those out leaving
just the patch data, if it'd make you feel better.

What are the legal ramifications of this?  DEC would seem to have some sort
of responsibility here, and if they've sold people a "secure" OS that every
high school kid is now cruising freely around in the middle of, well, hey.

_H*
-------

cetron%ced@CS.UTAH.EDU.UUCP (06/08/87)

Digital TSC has indicated that the security patch should be disseminated as
widely as possible so here it is. As usual, neither I nor the CED nor the Univ
of Utah take any responsibility for the patch after the network mail systems 
do their damndest.... as well as all the rest of the standard disclaimers...

this patch was correct, and worked, and passed the checksum before i mailed it.

-ed


The command file below is the patch for the security problem 
discussed at DECUS.  You must be running VMS V4.5.  Instructions 
for applying it are:

    1)  Place in file SYS$COMMON:[SYSUPD]SECURESHR.PAT as is.  
        If you edit it, it will not pass checksum checks.

    2)  Execute @SYS$COMMON:[SYSUPD]SECURESHR.PAT.

    3)  Either re-boot OR as I did, run SYS$SYSTEM:INSTALL and 
        REPLACE SYS$SHARE:SECURESHR.EXE.  This is the image that is
        patched.



$ CHECKSUM SECURESHR.PAT
$ X='CHECKSUM$CHECKSUM'
$ IF X.NE.%X652628B1 THEN GOTO IC ! 652628B1
$ ON WARNING THEN EXIT
$ SET DEFAULT SYS$COMMON:[SYSUPD]
$ COPY SYS$COMMON:[SYSLIB]SECURESHR.EXE SECURESHR.EXE
$ PATCH/JOURNAL=SECURESHR/OUTPUT=SECURESHR SECURESHR
!	ECO05	LMPxxxx		23-Jan-1987
!		MODULE: SYSUAISRV
!		Additional tweaks to ECO04.
!
!	ECO04	LMP0429		14-Jan-1987
!		MODULE: SYSUAISRV
!		Minor tweaks to ECO03.  Also, tweaks to GRPPRV handling.
!
!	ECO03	LMP0424		16-Dec-1986
!		MODULE: SYSUAISRV
!		Properly handle the context field.

DEFINE GETUAI=7C40
DEFINE SETUAI=7C40+37C

SET ECO 03

REP/INS GETUAI+1B3
'	BLSSU	GETUAI+212'
EXIT
'	BRB	GETUAI+212'
EXIT

REP/INS SETUAI+1BD
'	BLSSU	SETUAI+21D'
EXIT
'	BRB	SETUAI+21D'
EXIT
UPDATE

SET ECO 04

REP/INS GETUAI+86
'	BLSSU	GETUAI+99'
EXIT
'	BRB	GETUAI+99'
EXIT

REP/INS SETUAI+81
'	BLSSU	SETUAI+96'
EXIT
'	BRB	SETUAI+96'
EXIT

REP/INS GETUAI+295
'	BBS	#2,B^0D4(FP),GETUAI+2C2'
EXIT
'	BBC	#2,B^0D4(FP),GETUAI+2A5'
EXIT

REP/INS SETUAI+2DC
'	BBS	#2,B^0D4(FP),SETUAI+303'
EXIT
'	BBC	#2,B^0D4(FP),SETUAI+2ED'
EXIT
UPDATE

SET ECO 05

REP/INS SETUAI+314
'	MOVL	#24,R0'
'	RET'
EXIT
'	MOVL	#24,(SP)'
'	BRW	SETUAI+50B'
EXIT

REP/INS SETUAI+329
'	MOVZWL	#291C,R0'
'	RET'
EXIT
'	MOVZWL	#291C,(SP)'
'	BRW	SETUAI+50B'
EXIT

REP/INS SETUAI+386
'	MOVL	#14,R0'
'	RET'
EXIT
'	MOVL	#14,(SP)'
'	BRW	SETUAI+50B'
EXIT

REP/INS SETUAI+3A0
'	MOVZWL	#290C,R0'
'	RET'
EXIT
'	MOVZWL	#290C,(SP)'
'	BRW	SETUAI+50B'
EXIT

REP/INS SETUAI+3AA
'	MOVZWL	#2914,R0'
'	RET'
EXIT
'	MOVZWL	#2914,(SP)'
'	BRW	SETUAI+50B'
EXIT

REP/INS SETUAI+471
'	MOVZWL	#28E4,R0'
'	RET'
EXIT
'	MOVZWL	#28E4,(SP)'
'	BRW	SETUAI+50B'
EXIT

REP/INS SETUAI+4D3
'	MOVL	#0C,R0'
'	RET'
EXIT
'	MOVL	#0C,(SP)'
'	BRW	SETUAI+50B'
EXIT
UPDATE

EXIT
$ COPY SECURESHR.EXE SYS$COMMON:[SYSLIB]SECURESHR.EXE
$ DELETE SECURESHR.EXE.*
$ EXIT
$ IC:WRITE SYS$OUTPUT "INCORRECT CHECKSUM; VERIFY CONTENTS OF FILE"
$ EXIT

good luck,

	-ed

oberman@LLL-ICDC.ARPA.UUCP (06/10/87)

>Re: the magical patch.  I have several systems which can't afford to
>reboot often.  We were hoping to apply the patch at a reasonable time;
>i.e., when the machines were down anyway, say, for standalone backups.
>Now that it has been published, I know of several info-vax readers at
>our site who are intelligent enough to deduce how to get around things.
>This means I have to reboot these systems *before* they do.  Most of
>them won't bother, but one can't be sure...  Our manufacturing customers
>will undoubtedly give you hearty thanks.
>
>I will don my suit of armor for the time when, shortly after the required
>reboot, they wish to skewer me...

Why do you want to reboot? The patch certainly does not require it. Just
execute the .PAT file to patch the image and execute the following commands:
$ INSTALL :== $INSTALL/COMMAND
$ INSTALL
INSTALL> REPLACE SYS$LIBRARY:SECURESHR
INSTALL> EXIT
$

That does it. With no tar and feathers.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					arpa: oberman@lll-icdc.arpa
					(415) 422-6955

Disclaimer: Neither my employer nor myself can take resposibility for the
accuracy of this information. I believe it is correct, but if it's not I can
only say "Sorry".

------

STEWART_SYS@uta.EDU.UUCP (06/11/87)

Well, I for one received my Mandatory Update from DEC with the much talked
about security patch.  It is accompanied with a single sheet explaining
briefly how to install it.  It being the mandatory update, which, as the
sheet says, failure to install may compromise the integrity of your system.
It certainly doesn't mention what it's patching and why - just install it
and wait for the tape to self destruct.  

For those that have not yet received it or installed it, be warned that
once it finishes its patches, it reboots your system RIGHT NOW.  There is
no prompt for 'minutes to shutdown' or anything.  This sort of took me by
surprise.

As for the patch being sent over the net, I agree with the gent who cautioned
that anyone in between the path could have tampered with it.  It seems that if
it's security you're concerned with, then you're better off waiting for the
update from DEC.  Although I've heard a lot about this security hole, I've
not seen one message from anyone who has been victimized by it.  It is 
supposedly an obscure problem that requires some hacking to get to.  Now with
the patch published, potential hackers have been given a very good clue as
to where to dig.

The other item of concern is installing this and rebooting a production 
machine.  You don't have to reboot the machine for it to take effect.  DEc
does this to insure that the secureshr image is properly re-installed, but
a competent system manager should know (or be able to read up on) how to
re-install the image - no reboot necessary.

carl@CITHEX.CALTECH.EDU.UUCP (06/12/87)

 > Why do you want to reboot? The patch certainly does not require it. Just
 > execute the .PAT file to patch the image and execute the following commands:
 > $ INSTALL :== $INSTALL/COMMAND
 > $ INSTALL
 > INSTALL> REPLACE SYS$LIBRARY:SECURESHR
 > INSTALL> EXIT

Are you sure you don't want to do:

$ INSTALL:==INSTALL/COMMAND
$ INSTALL REPLACE SYS$LIBRARY:SECURESHR/OPEN/HEAD/SHAR/PROT

tedcrane@batcomputer.UUCP (06/15/87)

In article <870612112531.04h@CitHex.Caltech.Edu> carl@CITHEX.CALTECH.EDU (Carl J Lydick) writes:
> > INSTALL> REPLACE SYS$LIBRARY:SECURESHR
>Are you sure you don't want to do:
>$ INSTALL REPLACE SYS$LIBRARY:SECURESHR/OPEN/HEAD/SHAR/PROT

Doesn't the INSTALL REPLACE command _inherit_ the attributes of the
currently installed file?

It doesn't hurt to do what Carl describes, but it is redundant.

oberman@LLL-ICDC.ARPA.UUCP (06/18/87)

>Seems like one might want to use SYS$SHARE instead of SYS$LIBRARY just on
>principle (even though they are the same place).  I don't know whether
>SYS$SHARE is on its way in out, or whether they may be two different places
>in the future.  Maybe this is silly.

NO! Don't install from SYS$SHARE. It won't do a replace properly. SYS$LIBRARY
is a must.

INSTALL is weird in the way it processes logical names. It saves the
UNTRANSLATED logical name of known images. If you try to access a known
image (with INSTALL) by a logical other than the one which was used to install
it you will get a error that the entry was not found. This behaviour started
with VMS V4.]

DEC installs anything in SYS$SYSROOT:[SYSLIB] as SYS$LIBRARY. SYS$SHARE
is the same place, but it won't work on INSTALL. And while you could install
something from SYS$SHARE, it may cause confusion later if you forget how
it was installed.
					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					arpa: oberman@lll-icdc.arpa
   					(415) 422-6955

Disclaimer: Neither my employer nor myself can take resposibility for
the accuracy of this information. I believe it is correct, but if it's not I
can only say "Sorry".
------

bzs@bu-cs.BU.EDU (Barry Shein) (06/23/87)

Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix)



Re: people's concerns about distributing the patch via USENET...

Whether or not DEC has reason to be concerned that their patch went
out I think there is also another side to this issue which might calm
the waters...

Consider that between the ARPAnet and USENET distribution some (just
guessing, but probably in the right range) several hundreds of dollars
was just spent sending that patch out to thousands and thousands of
sites at essentially zero cost to DEC. Add to that all the FedEx tapes
and frantic phone calls and employees' time that was saved and I think
you can see what I am getting at, it's a two way street.

My opinion? Good, that's what networks are for, and DEC has always
been supportive of these networks in one way or another (strangely,
least from the VMS crew, no USENET, no UUCP, no ARPAnet, c'est la vie.)

It was probably one of the better uses of the bandwidth this
week.

	-Barry Shein, Boston University