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
Thanks to everyone for all the advice and tips etc regarding disk drives -
it is most helpful and very much appreciated!
Regards,
Andrew
On (23:48 18/09/09), gerry77 at mail.com wrote:
On Fri, 18 Sep 2009 14:39:03 +0100, you wrote:
I too have hardware in waiting - a growing collection. And if anybody is
able to help I have:
- A VAXstation 2000 in need of an RD53/54 and a KVM cable (mono)
I would like to point out that since about 1999 it is possible to use a SCSI
disk even in VAXstation 2000s, thanks to a patch that transforms the awful
almost-SCSI tape interface into a fully working SCSI disk interface! :)
The kit is made up of a patch for the console ROM plus patches for the SCSI
port driver for OpenVMS (PK2KDRVR.EXE) and other system images.
Look here: http://users.bart.nl/users/pb0aia/vax/vs-scsi.html
and here: http://ftp.gwdg.de/pub/vms/pk2k/
And if someone is not willing or not able to patch ROMs, there is also a boot
image that can be loaded via MOP or tape to start a SCSI boot from disk.
HTH, :)
G.
--
Andrew Back
a at smokebelch.org
Kari Uusim ki wrote:
Paul Koning wrote:
Excerpt of message (sent 18 September 2009) by Kari Uusim ki:
Andrew, have you tried other ST506 disks than RD53 or RD54? IIRC none of the RD disks were DEC built disks, but relabeled ones from other vendors.
That's true, but I think at least in some cases (and, perhaps, on some
systems, like a Pro) they required non-standard jumper configurations.
Also possibly low level formatting, which might require tools that
aren't easily available.
paul
Yes, low level formatting might be needed. If my memory serves me right, both VS2000 and the RQDX* have a low level formatting utility in the ROM.
I have to check that out.
The VS2000 have low level formatting routines in the firmware, the RQDX* don't.
Also, you can low level format a disk several ways, which all will work, but will produce different performance numbers for the disk.
The VS2000 formats the disk in a way that is optimal for the VS2000. It also works in a RQDX3 after that, but not optimally. This has to do with track skew and track interleave.
Johnny
Brian Hechinger wrote:
On Fri, Sep 18, 2009 at 10:07:21AM +0100, Sampsa Laine wrote:
That could work but like you said needs quite a bit of designing to work well - I would suggest that for now we maybe set up mirrors like FTP sites do, i.e. complete copies on more than one host, this way the bandwidth load is at least shared.
Does anyone have any objection to a private bittorrent tracker? It would
help with the centralized management/searching/etc and if more than one
person has space to keep stuff it helps everyone overall with download
speeds.
Just a thought. :)
Speaking as someone who don't keep up with all the latest trends, do bittorrent work with something shared on DECnet?
Apart from that, I don't have a problem with people setting up things, and sharing, as long as you try to keep it to legal stuff only. VMS stuff in general would appear to be ok, since you need a separate license key to run it, and the distributions as such are pretty much free.
PDP-11 software is more difficult. I try to keep the stuff that is free around on MIM::, but I don't have a very good system for it right now...
(I also try to keep it up to date on ftp://ftp.update.uu.se/pub/pdp11/rsx, and I think I have it in better order there)
Johnny
