[Info-vax] Using VMS for a web server

[Jan-Erik Soderholm]

Bill Gunshannon skrev den 2015-06-09 13:46:
> In article <8dfc8$5576079d$5ed4324a$42996 at news.ziggo.nl>,
> 	Dirk Munk <munk at home.nl> writes:
>> Stephen Hoffman wrote:
>>> On 2015-06-08 18:58:09 +0000, johnwallace4 at yahoo.co.uk said:
>>>
>>>> On Monday, 8 June 2015 16:35:04 UTC+1, li... at openmailbox.org  wrote:
>>>>> It is an unknown on VAX, Alpha, and Itanium.
>>>
>>> I've documented cases of malware on OpenVMS, and I've reproduced one or
>>> two of the more recent weaknesses — successfully — on OpenVMS.   It's
>>> rare, but it happens.
>>
>> How did the malware enter the VMS system?
>
> I have no experience with it but doesn't the same PHP run on VMS
> that runs on other OSes?  There's a hole big enough to drive a
> Mack truck through.
>
>>
>>>
>>> I've also encountered and resolved cases with OpenVMS servers that were
>>> parts of DDoS botnets, too.  OpenVMS has been subject to a couple of
>>> those in recent years, too.  Everybody is patched to current, of course?
>>>
>>
>> How does something like that work? As far as I'm aware these are
>> executables, so how do they get on the VMS system, and how do these
>> hackers get them running?
>
> Doesn't VMS support PHP?  Great attack vector.  Allows the execution of
> arbitrary commands.  On Unix I have seen attackers use PHP scripts available
> through the web server to run the "fetch" command to copy a telnet daemon,
> written in PHP, to any writable directory they can guess at (in the past
> it was just /tmp, but hopefully today no one allows executables there to run).
> They then use the same method to run it and voila.  Don't know if the same
> method would work on VMS, but being as it is a PHP hole, I see no reason
> why not.
>

You would normaly run your server process (where the PHP code runs)
using a dedicated username that doesn't have access to anything it
doesn't need for normal processing.

It would be simple to either review or actualy test something
if you can point at a reproducer.

But yes, PHP programmers have an habbit to simply concatenate
input params from the user with the rest of the SQL statement.
That make SQL injection very simple, just write an SQL
statement in the input box instead of the expected value.

If one uses SQL parameter markers that is simply impossible.
All my Python code uses paramater markers since that is the
"normal" way to interface to Rdb. The user has no way from
the web page to interfere with the actual SQL code.



>>
>>>>> As soon as VMS runs on Intel and uses an Apache port it's essentially
>>>>> no longer VMS.
>>>
>>> That's not how remote security attacks work.  The remote attacks are
>>> always and inherently further up the stack than the instruction set.
>>> What happens with an injection or cross-site scripting or some other
>>> attack varies.  Executable code is not particularly portable across
>>> operating systems.  Though on OpenVMS, attackers can leverage the
>>> OpenVMS virtual memory layout rather more effectively than on systems
>>> that intentionally randomize library placement and stack organization.
>>> (Windows can even reverse the stack direction, though that's not
>>> commonly used.)
>>>
>>>>> Running on a less common architecture is in itself a fairly effective
>>>>> means of security by obscurity.
>>>
>>> OpenVMS is presently — and unfortunately — running down-revision
>>> software, with known attacks.
>>>
>>
>> We all know how HP neglected VMS maintenance.
>>
>>>>> Most exploits start out in C code that has buffer overruns or does
>>>>> other stupid programming tricks.
>>>
>>> The Microsoft Security folks have posted some pretty good data on the
>>> recent changes and the sorts of attacks being seen, both in general and
>>> on Windows itself.  Trends for Windows security are decent, too.  Fetch
>>> Microsoft SIR volume 18 from
>>> http://www.microsoft.com/security/sir/default.aspx and start reading.
>>>
>>>>> A lot of (most?) exploits are in web-facing stuff like PHP, bash CGI
>>>>> scripts, and various SQL servers. It remains to be seen how far you
>>>>> could get on VMS with all that junk ported to VMS running
>>>>> on Intel but even if you could only get as far as the database you
>>>>> could still do a lot of damage without having any VMS-specific
>>>>> exploit code at all.
>>>
>>> If an attacker can execute code or get shell access, the server is
>>> toast.   Whether that's PowerShell or bash or DCL or otherwise.   With
>>> OpenVMS, other issues can arise with HP-specific packages and tools that
>>> are vulnerable, as well.  There have been various remote attacks against
>>> HP server infrastructure underneath OpenVMS that have been remediated —
>>> are you running current firmware everywhere?  Current remote-management
>>> tools?
>>>
>>>> Folk can have a look at the exposure descriptions on (say) the CVE
>>>> database (see below) and once they've identified the relevant details
>>>> they can make an informed assumption (!) about which exploits will be
>>>> reproducible on VMS. If they don't have the relevant expertise
>>>> themselves, there may be people that do.
>>>
>>> A fair amount of attacks do not have CVEs, unfortunately.
>>>
>>>> SQL injection and similar stuff where the hole is in the platform
>>>> (PHP/*SQL/etc) not the OS (Windows etc) will largely be OS independent.
>>>
>>> Cross-site scripting and SQL injection and the rest are
>>> platform-independent, and can hit OpenVMS now.
>>>
>>>> Broken source code is broken everywhere (give or take).
>>>
>>> Ayup.
>>>
>>>> E.g. Confusing a number between signed and unsigned, or failing to
>>>> correctly check a parameter string for illegal contents, isn't
>>>> particularly dependent on OS or on hardware architecture.
>>>
>>> Having only the older C APIs on OpenVMS doesn't really help things; more
>>> than a few calls can or should be flagged and removed from existing
>>> code.  OpenBSD has gone to no small effort to harden the operating
>>> system and the applications, well beyond what is possible and feasible
>>> on present-day OpenVMS.
>>>
>>>> In fact what's exploitable on x86 already isn't the same as what's
>>>> exploitable on another x86 running nominally the same OS, if one of
>>>> them is in 32bit mode and the other is in AMD64 mode.
>>>
>>> I suspect no one here is going to convince lists of that.    But then
>>> lists should hopefully be starting to port all of the local OpenVMS code
>>> elsewhere, given VSI plans.
>>>
>>>> Have a look, see what you think. Don't believe *everything* you read.
>>>
>>> Don't believe that OpenVMS is entirely secure, either.
>>
>> No, but it was *designed* to be safe. With proper maintenance it should
>> be possible to make it very safe again I suppose.
>
> With proper maintenance any OS is secure.  Back when I was working there
> DISA published SRR's, Security Readiness Reviews.  These had you go thru
> your system and pointed out things that, if open, should be closed.  There
> was one for VMS as well as Unix, Windows and pretty much every current
> serious OS.
>
> bill
>
>