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
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
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
Cool, thanks for that, I'll put it into my advisory if I issue one, with credit to you of course :)
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
Quick update: I've had a guy from HP's OpenVMS and Tru64 Apache team contact me, they're working on a fix. Turns out it's limited to MOD_PHP apparently, not all of CSWS.
Sampsa
On 21 Sep 2009, at 21:46, Brian Hechinger wrote:
On Mon, Sep 21, 2009 at 08:17:02PM +0100, Sampsa Laine wrote:
Guys,
What do you guys think, worth getting in touch with HP? I think this
could be a potential disaster waiting to happen...
A VMS Guru friend of mine replied with this:
=======================================================================
Not surprising. I would guess that the source code makes some
bad assumptions about file specifications.
It should definitely be reported to HP.
=======================================================================
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
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
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.
I'm trying to be reasonably "responsible disclosure" about this, so please don't spread the news TOO widely before HP gets a chance to fix this (== no posts to comp.os.vms or 'Full Disclosure' please :) but feel free to warn any responsible parties you think need a heads up.
I will be posting an advisory later to Bugtraq or some such once HP has managed to fix the issue.
Sampsa
On 21 Sep 2009, at 21:46, Brian Hechinger wrote:
On Mon, Sep 21, 2009 at 08:17:02PM +0100, Sampsa Laine wrote:
Guys,
What do you guys think, worth getting in touch with HP? I think this
could be a potential disaster waiting to happen...
A VMS Guru friend of mine replied with this:
=======================================================================
Not surprising. I would guess that the source code makes some
bad assumptions about file specifications.
It should definitely be reported to HP.
=======================================================================
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
On Mon, Sep 21, 2009 at 08:17:02PM +0100, Sampsa Laine wrote:
Guys,
What do you guys think, worth getting in touch with HP? I think this
could be a potential disaster waiting to happen...
A VMS Guru friend of mine replied with this:
=======================================================================
Not surprising. I would guess that the source code makes some
bad assumptions about file specifications.
It should definitely be reported to HP.
=======================================================================
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Guys,
I just installed CSWS (== Apache basically) on RHESUS and think I've found what amounts to potentially rather annoying security problem: CSWS doesn't seem to fully understand VMS file specifications, so it treats the semi-colon that indicates version numbers after an extension as part of the extension, thus allowing one to access the source code of CGIs or PHP scripts etc.
As an example, there is a plain vanilla CSWS install with CSWS_PHP running on RHESUS. If you access the following URL:
http://rhesus.sampsa.com/php/php_rules.php
You will get the script's output.
However, if you append ;1 to the filename, you get the PHP source instead:
http://rhesus.sampsa.com/php/php_rules.php;1
Which might contain database credentials, trade secrets, or even my Illuminati membership number...
What do you guys think, worth getting in touch with HP? I think this could be a potential disaster waiting to happen...
Sampsa
The revisions after V8, can be turned back into something usable if you
are willing to put in a few patches and custom run-time-systems. It has
been many years since I did anything useful with RSTS, but the big push
by DEC to make everyone DCL compliant was where RSTS got messed up and
slow. Like Paul, "if" I get some time I'd like to put up a few RSTS
systems on rsts.org and tie them to hecnet, but real work always gets in
the way.
Brett
On Thu, 20 Aug 2009, Mark Abene wrote:
Yeah, if I didn't think that every version of RSTS after v8 is a total
abomination. :) I run v8 on purpose, because I actually used to use it
back in the 80's. It's the last "pure" version, before DEC turned it
into crap to make VMS people happy.
-M
Paul Koning wrote:
Excerpt of message (sent 20 August 2009) by Mark Abene:
While I have been running three public access emulated systems for a few
years now (TOPS-20 on KLH10, RSTS/E v8 and 2.11BSD on SIMH), there are
several problems with me getting on HECnet. First, my host server is
FreeBSD, and FreeBSD doesn't support multicast on tap network
interfaces, nor have I heard about any plans to. Which means no DECnet.
At some point I plan to migrate my emulators over to a beefy linux
server, and linux does have the necessary support. Second problem, is
that SIMH doesn't support any DDCMP-aware network devices, which means
that even if I solve the first problem (it'll allow me to get TOPS-20 on
DECnet), I don't have any way via SIMH to get DECnet/E working on my
RSTS system. Call me crazy, but I just don't think I'll be paying 4,000
dollars for E11/linux. So that's out.
Could you get RSTS/E V10? If so, you could run DDCMP over an async
terminal line.
paul
