home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.vms
- Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!ux1.cso.uiuc.edu!news.cso.uiuc.edu!jsue
- From: jsue@ncsa.uiuc.edu (Jeffrey L. Sue)
- Subject: Re: HELP!!! Security problem for gurus.
- References: <Bz1nrE.ALq@unx.sas.com> <1992Dec19.025940.1@us.oracle.com> <1992Dec22.161918.9033@ncsa.uiuc.edu>
- Message-ID: <1992Dec22.184359.20436@ncsa.uiuc.edu>
- Originator: jsue@mars.ncsa.uiuc.edu
- Sender: usenet@news.cso.uiuc.edu (Net Noise owner)
- Organization: The Dow Chemical Company
- Date: Tue, 22 Dec 1992 18:43:59 GMT
- Keywords: hack security files-11 protection
- Lines: 130
-
- This is strange, following up my own post, but I made some statements that
- weren't entirely correct. After more testing here's my results:
-
- In article <1992Dec22.161918.9033@ncsa.uiuc.edu> jsue@ncsa.uiuc.edu (Jeffrey L. Sue) writes:
- >
- >I want to warn anyone using "unsupported" VMS techniques like putting the
- >directory below 8 levels deep, renaming the .DIR to something else (e.g.,
- >.DAT), or completely munging the directory.
- >
- >If this information is important to you, then just realize that VMS BACKUP
- >will "lose" this information in the event of a full disk restore. Also,
- >if ANALYZE/DISK/REPAIR (before or after the restore) will place these files
- >in [SYSLOST].
-
- NOTE: ANALYZE/DISK/REPAIR and VMS BACKUP neither one "lost" the files
- in my example. They were in the saveset, with "[]" as the directory.
-
- >
- >Just to see what would happen, I used my V5.5-2 system to create a directory
- >16 levels deep and created a file in it. This is [X1...X16]XXXX.XXXX
- >
- >Also, I created [YY]TEST1.DAT and then renamed yy.dir to ZZ.DAT. Here is
- >the backup listing that resulted.
- >
- >*********************
- >Listing of save set(s)
- >
- >Save set: X.BAK
- >Written by: S084349
- >UIC: [000001,000005]
- >Date: 22-DEC-1992 11:02:20.98
- >Command: BACKUP/IMAGE DISK$VUSER2: DISK$VUSER1:[000000]X.BAK/SAVE
- >Operating system: VAX/VMS version V5.5
- >BACKUP version: V5.5-2
- >CPU ID register: 13000202
- >Node name: _CRVS02::
- >Written on: _$1$DKA200:
- >Block size: 32256
- >Group size: 10
- >Buffer count: 116
- >
- >Image save of volume set
- >Number of volumes: 1
- >
- >Volume attributes
- >Structure level: 2
- >Label: VUSER2
- >Owner:
- >Owner UIC: [000001,000004]
- >Creation date: 9-DEC-1992 07:39:39.87
- >Total blocks: 1316751
- >Access count: 3
- >Cluster size: 3
- >Data check: No Read, No Write
- >Extension size: 5
- >File protection: System:RWED, Owner:RWED, Group:RE, World:
- >Maximum files: 164593
- >Volume protection: System:RWCD, Owner:RWCD, Group:RWCD, World:RWCD
- >Windows: 16
- >Minimum retention: 30 00:00:00.00
- >Maximum retention: 30 00:00:00.00
- >
- >[000000]BACKUP.SYS;1 0 9-DEC-1992 07:39
- >[000000]BADBLK.SYS;1 0 9-DEC-1992 07:39
- >[000000]BADLOG.SYS;1 0 9-DEC-1992 07:39
- >[000000]BITMAP.SYS;1 109 9-DEC-1992 07:39
- >[000000]CONTIN.SYS;1 0 9-DEC-1992 07:39
- >[000000]CORIMG.SYS;1 0 9-DEC-1992 07:39
- >[000000]DEFRAG.DIR;1 1 12-DEC-1992 14:36
- >[DEFRAG]$1$DKA0_PIC.LIS;1 13 12-DEC-1992 15:33
- >[DEFRAG]$1$DKA200_PIC.LIS;1 10 12-DEC-1992 16:56
- >[000000]INDEXF.SYS;1 1062 9-DEC-1992 07:39
- >[000000]OFFLOAD.DIR;1 1 12-DEC-1992 14:41
- >[000000]PATCHES.DIR;1 1 10-DEC-1992 09:08
- >[000000]SCR.DIR;1 1 12-DEC-1992 14:41
- >[000000]SYSLOST.DIR;1 1 9-DEC-1992 07:39
- >[000000]VOLSET.SYS;1 0 9-DEC-1992 07:39
- >[000000]X1.DIR;1 1 22-DEC-1992 10:48
- >[X1]X2.DIR;1 1 22-DEC-1992 10:48
- >[X1.X2]X3.DIR;1 1 22-DEC-1992 10:48
- >[X1.X2.X3]X4.DIR;1 1 22-DEC-1992 10:48
- >[X1.X2.X3.X4]X5.DIR;1 1 22-DEC-1992 10:48
- >[X1.X2.X3.X4.X5]X6.DIR;1 1 22-DEC-1992 10:48
- >[X1.X2.X3.X4.X5.X6]X7.DIR;1 1 22-DEC-1992 10:48
- >[X1.X2.X3.X4.X5.X6.X7]X8.DIR;1 1 22-DEC-1992 10:48
- >[X1.X2.X3.X4.X5.X6.X7]X9.DIR;1 1 22-DEC-1992 10:50
- >[X1.X2.X3.X4.X5.X6.X7.X9]X10.DIR;1 1 22-DEC-1992 10:50
- >[000000]ZZ.DAT;1 1 22-DEC-1992 11:01
- >[]000000.DIR;1 2 9-DEC-1992 07:39
- >[]TEST1.DAT;1 1 22-DEC-1992 11:01
- >[]X11.DIR;1 1 22-DEC-1992 10:50
- >[]X12.DIR;1 1 22-DEC-1992 10:50
- >[]X13.DIR;1 1 22-DEC-1992 10:50
- >[]X14.DIR;1 1 22-DEC-1992 10:50
- >[]X15.DIR;1 1 22-DEC-1992 10:50
- >[]X16.DIR;1 1 22-DEC-1992 10:50
- >[]XXXX.XXXX;1 1 22-DEC-1992 10:50
- >
- >Total of 35 files, 1220 blocks
- >End of save set
- >
- >**************************************
- >NOTE: All files and directories will not be restored correctly if a disk
- > problem occurs.
- >
-
- My NOTE above is completely incorrect. All files and directories are
- restored during a full disk restore (BACKUP/IMAGE restore). However,
- if a backup /SELECT=[mydir...] were performed to restore my files,
- then the files hidden will not be restored. This effectively breaks
- things like SLS or TAPESYS, which depend on the listing and /SELECT
- qualifiers to find and restore files.
-
- The surprising thing to me is that using directory levels below X9 does
- not cause any errors! Not even ANALYZE/DISK/REPAIR will point them out.
- This does create a neat way to hide files, however anyone who has privs enough
- to look around in my directory can also see that I have .DIR files at level
- 9 and define the necessary logical to start looking in there as well. In
- fact, it might even be more obvious to such a person that I have something
- to hide, since he/she can merely do a DIRECTORY:[*.*.*.*.*.*.*.*.*] just to
- see if anything shows up.
-
- My definite favorite is using the MAIL$bignumber.MAI to hide them.
- Nothing's better than hiding in plain sight.
-
-
- --
- -----
- Jeff Sue
- - All opinions are mine - (and you can't have any, nya nya nya)
-