[Info-vax] Using VMS for a web server

[Dirk Munk]

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

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