[HECnet] Security hole in CSWS

Tue Sep 22 22:00:35 PDT 2009

Oh, I should probably correct myself a little as well.

I (as in really me) should write FILES-11 when I talk about this, except when I really mean to discuss the actual differences between the different versions.
That's what ODS-1, ODS-2 and ODS-5 is for.

When we talk about the file system in general, FILES-11 is perfectly fine. If we want to discuss differences between the different versions, then we obviously must specify which version we're talking about.
But they all share a lot of common concepts, and such, can normally be talked about under the general name FILES-11.
Such general concepts are things like files are identified by file IDs, and that files presents "raw" blocks to the system. You also have some special files that they all have, which are parts of the fundamental concepts of FILES-11, such as an INDEXF.SYS, 000000.DIR, and some more .SYS files.
These "special" files have specific file ID numbers, so that they can be found without ever doing any filename lookups.

This is actually very similar to how things work on Unix file systems (well, filesystems that are similar to UFS anyway), in which you have inodes, which hold the basic information about a file. In FILES-11, that is held in INDEXF.SYS, and is located by the file ID number, just as you have i-node numbers in UFS.

For FILES-11 to work, this also means that a part of INDEXF.SYS are always in a known location on the disk, so it can be found without any other information at all. All other files can then be found based on the information in INDEXF.SYS

FILES-11 have a few basic concepts only. A file is a sequence of blocks. No further interpretation is done. A file also have a number of allocated blocks. Finally, a file have a small storage area (in ODS-1 it is 16 bytes, not sure if it is the same size in ODS-2), where normally you can store whatever you want, which is also associated with the file. This is the place where FCS and RMS stores file attributes of all kind. You can actually write anything you want into these bytes, but don't expect RMS or FCS to be happy operating on the file if you do. You'll have to talk directly to FILES-11 in that case, in order to play with the file. :-)

Feel free to ask if there is anything more you want to know. My knowledge of ODS-2 and ODS-5 aren't as good as ODS-1, but I think I know most of it anyway (for ODS-1, I have done a lot of playing around...)

	Johnny

Sampsa Laine wrote:
Ok, noted, will work that into the text :) Well I'll try anyway.
I have some time as I'm waiting on the Apache guys from HP to publish their article first.
Sampsa
On 22 Sep 2009, at 21:34, Johnny Billquist wrote:
Ok. A few more comments.
ODS-1 was indeed used in VMS, and I think it is still supported, but
ODS-1 is read-only (atleast nowadays).
ODS-2 brought long filenames, as well as some more information in the
file headers to make it easier to recover lost files.
ODS-5 added lowecase filenames, basically allowing all characters in
filenames, and maybe some other stuff I can't remember right now.

I don't think it is right to claim any relationship between ODS, and
whatever disk structure used on RSTS/E or TOPS-20.

It would be much more correct to just say that current VMS file systems
are direct descendants of ODS-1, which is used in RSX. I even have the
patches somewhere to make RSX use ODS-2 instead, if wanted.
The changes are pretty small in reality.

Also, you are confusing ODS with RMS in the next section. ODS as such
only presents raw blocks to the next level. It is RMS (or in the case of
RSX - RMS or FCS) that presents you with the abstract file attributes,
records, formats and so on. It has nothing to do with ODS.

The RMS system between RSX and VMS is pretty much compatible, but with
VMS having a superset of the things RSX can do. But unless you start
doing really tricky stuff, you will not notice any difference (the
differences are in file locking mechanisms, some weird key types, and
reading data backwards).

The file versioning stuff on the other hand is something that is handled
by ODS.

And I shouldn't really write "ODS", I should write "FILES11". :-)

      Johnny

Sampsa Laine wrote:
That is EXACTLY the kind of glaring inaccuracies I was looking for..
Cheers.
Sampsa
On 22 Sep 2009, at 21:03, Steve Davidson wrote:
Sampsa,

TOPS-20 never ran on a PDP-11.   TOPS-20 ran on the 36-bit DECsystem-20.

-Steve

-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Sampsa Laine
Sent: Tuesday, September 22, 2009 15:56
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Security hole in CSWS

Guys, I've written a quick blurb about the flaw I found etc that I'm
posting on my blog once the Apace guys say they're releasing it.

Comments? Glaring factual inaccuracies? The intended audience is a
fairly technical bunch, prob mostly infosec consultants and pentesters.

http://rhesus.sampsa.com/csws-flaw/

On 22 Sep 2009, at 20:34, Sampsa Laine wrote:

It appears that
            RewriteRule (;[0-9]*\?)|(;[0-9]*$) [R]

works as well.

The VMS Apache guys know about this and are working on it as we
speak, but I would suggest letting any clients etc know about this
before the formal advisory goes out as I should think this will hit
the automated testing tools such as Nessus pretty soon after that.

Sampsa

On 22 Sep 2009, at 20:27, Pontus wrote:

Hi

I'm not going to pretend I know mod_rewrite, but I spent some time
with
the docs and thought you could use the grouping info to replace with
what you matched:

(.*)(;[0-9]*\?) $1
(.*)(;[0-9]*$) $1

(I wrote two rules as I'm uncertain how the | binds)

Alternatively this passage from the docs might provide an alternative
solution:

<snip>

Additionally you can set special flags for Substitution by appending

[flags]

as the third argument to the RewriteRule directive. Flags is a
comma-separated list of the following flags:

<...>

- *||*'forbidden|F' (force URL to be forbidden)
This forces the current URL to be forbidden, i.e., it immediately
sends
back a HTTP response of 403 (FORBIDDEN). Use this flag in conjunction
with appropriate RewriteConds to conditionally block some URLs.

</snip>

Then you could at least avoid people reading the source.

/Pontus.

Sampsa Laine wrote:
Dennis,

I've got the rule down to:

RewriteRule (;[0-9]*\?)|(;[0-9]*$) /

but this is not ideal, as I don't really want to replace the ;
with a
/, just drop it but can't figure out the syntax for "replace with
nothing".

Any ideas?

Sampsa

On 21 Sep 2009, at 22:12, Dennis Boone wrote:

Yes, I have reported it to VMS engineering in India about an
hour ago
(well I assume in India, the guys had subcontinent accents) and
they
said they'd get back to me.

In the meantime, if CSWS has mod_rewrite, you might be able to
produce a
temporary fix in the form of a rewrite rule that rips the ;* off
the
end[1]
of .php urls.

[1] Well, ok, might be the middle too, if it's a GET with
parameters,
but that's just a slightly more involved pattern.

De

-- 
Johnny Billquist                                   || "I'm on a bus
                                                                ||   on a psychedelic trip
email: bqt at softjar.se                         ||   Reading murder books
pdp is alive!                                         ||   tryin' to stay hip" - B. Idol

-- 
Johnny Billquist                                   || "I'm on a bus
                                                                  ||   on a psychedelic trip
email: bqt at softjar.se                         ||   Reading murder books
pdp is alive!                                         ||   tryin' to stay hip" - B. Idol