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

Internet Message Format | 1993-01-01 | 6.9 KB

Path: sparky!uunet!portal!cup.portal.com!Chris_F_Chiesa
From: [e-mail]
Newsgroups: comp.os.vms
Subject: re: Re: HELP!!! Security problem for gurus. [Directories]
Message-ID: <[e-mail]>
Date: Fri,  1 Jan 93 18:16:57 PST
Organization: The Portal System (TM)
Distribution: world
References:  <[e-mail]>
Lines: 134

In yet another recent article (Portal does not permit me to identify the
article more specifically) here, Jerry Leichter (Portal also doesn't in-
sert Jerry's Internet address here for me, and Jerry doesn't sign off
with it) responds to an earlier posting of MINE.  Jerry also sent me a
copy of his article via e-mail, but I'm responding here as I think this
thread is probably of general interest...

>    On the thread of protecting a directory, [...]
>
>    [...] "the undocumented DUMP/DIR command." [...] 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.

For what it's worth, I have it on my V5.4-3 system, and I haven't checked
for it on my one V5.5 system...

>    One of the fields shown was "TYPE" at offset 4.  [...] it had
>    the exact same value [...] for ALL directory entries in ALL
>    .DIR files.  I wondered what OTHER valid values for that field
>    existed [...]
>
>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.

Being unfamiliar as I am with the specific behavior of "a Unix 'soft link',"
can you elaborate on the intended behavior of this interesting-sounding
never-implemented feature?  I'm just wondering what we're missing out on.

>(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).

Very interesting!  What's a "hashed" file type?  Again, can you elaborate?
This may be a loaded question, but: how does it happen that features can
BE "spec'd but never implemented?"  What determines whether a particular
feature gets implemented right away, or after a long delay (how long has
ODS-II been in existence with spec'ed-but-never-implemented features?),
or never?  And, finally, how do YOU find out about these things, Jerry?
Inquiring minds... etc. ;-)

>    I also found that if I put an INVALID value [...] into that field
>    in the FIRST entry in the .DIR file [...] 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.
>
>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.

It seems evident from what I've observed, that DIRECTORY doesn't (currently)
validate at least the contents of the "type" field I played with -- but I'm
afraid I don't see how it makes any difference whether one "accesses the
directory files directly" OR "(goes) through RMS."  If I open "filespec.DIR"
as a FILE, I can read it just fine using RMS -or- "directly."  Do I mis-
understand you, Jerry?

>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?)

Ehhhhhh...  I'm afraid you've caught me out, here, Jerry.  I did ONLY
a "DIRECTORY" command and a "DIRECTORY filespec" command - didn't try
/DATE or /SIZE or any of the file-header-access-requiring qualifiers.
I'll try this and get back to this thread, if someone else doesn't beat
me to it as seems highly probable.

>    I expect that this technique--
>
>     [...]
>
>      c) would stymie any system manager, probably any CSC representative,
>         who hasn't read this post just now, regardless of privs;
>
>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].

Didn't think of that.  I can count the number of times I've done an
ANALYZE/DISK in my six-year VMS career (four of them as a system manager
of a very small system) on the fingers of one hand, and I don't think
I've EVER used /REPAIR...

>If you want to hack with directory entries, there are plenty of other things
>you could do.

Some very interesting ideas, Jerry -- thanks!  I'll have to do some "playing!"
(Yeah, it WILL probably require me to use ANALYZE/DISK again afterwards,
and maybe /REPAIR for the first time ;-) )

> [...] you are safe only as long as the
>file isn't noticed.

Ah, that's the bottom line, isn't it...  Sometimes the best place to hide
something is right out in plain sight... "The Purloined Letter" taught us
that, a long time ago... ;-)

>BTW, it's not impossible that SOME invalid directory entries will could cause
>(probably non-fatal) bugchecks.

I remember seeing RMS bugs in the past that would delete the erring process
upon encountering certain errors in on-disk or file structure.  I was always
surprised to find such dramatic bugs in RMS, an otherwise extremely robust-
seeming entity...

> 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!

That's VERY interesting!  At what level of the system would this be imple-
mented?  Disk driver (mark certain media blocks /NOWRITE)?  $QIO-ACP inter-
face ("don't allow access to any file whose "I'm a directory" bit is set")?
Write-Logical-(or-Physical)-Block $QIO request?  Blocking directory-write
access at any level would pose difficulties and paradoxes.  For example,
RMS needs to be able to update directories, which would seem to preclude
blocking directory-writing at the driver or $QIO levels, but NOT blocking
such access at those levels would hardly prevent "illegal" modifications
in the intended manner, as simply bypassing RMS would be sufficient...
Ah well, some combination of access-mode and file-attribute check could
be applied that would at least make "illegal" modification MORE DIFFICULT
than it is today.

Chris Chiesa
  [e-mail]