[Info-vax] Using VMS for a web server

[Stephen Hoffman]

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.

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?

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

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



-- 
Pure Personal Opinion | HoffmanLabs LLC