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

Internet Message Format | 1992-12-29 | 5.1 KB

Path: sparky!uunet!elroy.jpl.nasa.gov!ames!agate!ucbvax!lrw.com!leichter
From: [e-mail] (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re: Re: HELP!!! Security problem for gurus. [Directories]
Message-ID: <[e-mail]>
Date: 29 Dec 92 01:30:55 GMT
Sender: [e-mail]
Distribution: world
Organization: The Internet
Lines: 99


    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.

Hmm - DUMP/DIR seems to have been added recently; there's no such qualifier
on my V5.2 systems.

    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.

Interesting.  The ODS-II specs, as best I can recall, define two possible
entry types:  Files and links.  Files are what you would expect.  A link is
a like a Unix "soft link":  A text string that replaces the file specifica-
tion being parsed.  While specified way back when ODS-II was first designed
(i.e., when VMS was designed), this feature has never been implemented.

(ODS-II has several other "spec'ed but never implemented" features, including
a hashed file type and something I gather will finally appear in VMS V6:
Access-mode restricted files (i.e., files that can only be accessed from
inner-mode code, regardless of the usual protections on the file).

    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 believe DIRECTORY accesses the directory files directly, rather than going
through RMS.  It probably doesn't check the validity of the entries it sees.

Just out of curiosity (since you've done this already), did DIRECTORY work
when you were looking at more than just the file spec?  (Every other field -
well, every other field except the file id - requires access to the file's
header.  Did DIRECTORY manage to access the header?)

    I expect that this technique--

      a) is unsupported; use at your own risk;

You bet.

      b) does NOT involve changing the ATTRIBUTES (protection, "directory"
         bit, etc.) of the .DIR file;

No, only the contents.

      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.

Actually, I have serious doubts about c.  ANALYZE/DISK is pretty certain to
check directory entries for validity.  Your munged entries will stand out
like a sore thumb.  It's a good bet that ANALYZE/DISK/REPAIR would fix the
invalid entries by removing them and then later noticing the files involved
are lost and moving them to [SYSLOST].

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

If you want to hack with directory entries, there are plenty of other things
you could do.  For example, you could change the last character in the file's
name to something like a space or a backspace.  The file would be inaccessible
through that name until the entry was patch back.  I don't know if
ANALYZE/DISK - or even RMS - would notice this and complain; probably not.
But anyone who actually tried to access the file would quickly learn that
you were playing games.  A quick DIR/FILE, along with a program to access a
file directly by FID, and that would be that.  No safer than just giving the
file an innocuous name to begin with, since you are safe only as long as the
file isn't noticed.

It's not clear to me what BACKUP would do with a hacked directory entry.  It
might complain, making the hacked files VERY visible during the next system
incremental.

BTW, it's not impossible that SOME invalid directory entries will could cause
(probably non-fatal) bugchecks.  Also, the future direction of VMS seems to be
to forbid direct access to directory files (at least direct write access).
You could find your modified directory entries completely inaccessible after
the next upgrade!
                            -- Jerry