NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/vms/19896

Internet Message Format | 1992-12-26 | 2.5 KB

Path: sparky!uunet!portal!cup.portal.com!Chris_F_Chiesa
From: [e-mail]
Newsgroups: comp.os.vms
Subject: Re: HELP!!! Security problem for gurus.
Message-ID: <[e-mail]>
Date: Fri, 25 Dec 92 23:53:17 PST
Organization: The Portal System (TM)
References: <[e-mail]>
  <[e-mail]> <[e-mail]>
Lines: 42

On the thread of protecting a directory, I found something recently that
might prove applicable...

I was reading through printouts of old postings from this newsgroup,
and happened across mention of "the undocumented DUMP/DIR command."  I
tried it (you try it, now, too) and found that it displays the contents
of a .DIR file, in terms of its significance as file-directory information
and including its offset, in bytes, from the beginning of the .DIR file.

One of the fields shown was "TYPE" at offset 4.  I noticed that it had
the exact same value (I don't have a VMS system handy at the moment so
can't tell you what value that was) for ALL directory entries in ALL
.DIR files.  I wondered what OTHER valid values for that field existed,
and so I whipped out my copy of VFE (the Virtual File Editor, a PD
thing available from DECUS) and patched a different value into offset
4.  I found that there were several values which DUMP/DIR "knew about,"
whose purpose is as yet unknown to me.

I also found that if I put an INVALID value -- i.e., something DUMP/DIR
didn't recognize (or was it, specifically, the value 0?  I forget; try
experiments, I did!) -- into that field in the FIRST entry in the .DIR file,
a funny thing happened: I was able to do a DIRECTORY operation on the
directory represented by the patched .DIR file, but was UNABLE to access
any of the FILES THEMSELVES.  Patching the original value, whatever it
was, back into that field, made everything work normally again.

I expect that this technique--

  a) is unsupported; use at your own risk;
  b) does NOT involve changing the ATTRIBUTES (protection, "directory"
     bit, etc.) of the .DIR file;
  c) would stymie any system manager, probably any CSC representative,
     who hasn't read this post just now, regardless of privs;
and
  d) could be implemented in a nice little PROGRAM that went out and
     tweaked the appropriate field in the .DIR file, letting you easily
     protect and deprotect a directory at your convenience.

Use at your own risk, of course.  Bon chance!

Chris Chiesa
  [e-mail]