[Info-vax] Using VMS for a web server

[johnwallace4 at yahoo.co.uk]

On Monday, 8 June 2015 16:35:04 UTC+1, li... at openmailbox.org  wrote:
> On Mon, 08 Jun 2015 15:59:43 +0200
> Dirk Munk via Info-vax <info-vax at rbnsn.com> wrote:
> 
> > Jan-Erik Soderholm wrote:
> > 
> > >>
> > >> What happened to "the right tool for the job".  Just what is it about
> > >> VMS that makes it a better choice for running a webserver than one of
> > >> the existing Unix options?
> > >
> > > It is "better" if the source data already is on VMS.
> > > In no other case is VMS "better" as an web server.
> > > Noone would get a VMS system *only* to run a web server...
> > 
> > Depends on your needs and wishes. I still remember the competition where 
> > hackers were invited to hack a VMS system, and they didn't succeed.
> > 
> > VMS web servers are unknown, and that in itself is a safety advantage.
> 
> It is an unknown on VAX, Alpha, and Itanium. As soon as VMS runs on Intel
> and uses an Apache port it's essentially no longer VMS.
> 
> Running on a less common architecture is in itself a fairly effective means
> of security by obscurity. But since most of the attacks now focus on open
> source vulnerabilities and AlL YoUR OS bELoNg 2US with everybody running
> parts of a small subset of crapware (Apache/PHP/MYSQL/BrokenSSL) on the
> same crapware hardware platform, using VMS as a webserver in the future is
> probably not going to add any value except as you say if you have the data
> there already (and don't care about it that much.)
> 
> Most exploits start out in C code that has buffer overruns or does other
> stupid programming tricks. 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.
> 
> -- 
> Please DO NOT COPY ME on mailing list replies. I read the mailing list.
> RSA 4096 fingerprint 7940 3F02 16D3 AFEE F2F8  ACAA 557C 4B36 98E4 4D49

Once again, lots of words and no TLDR. Sorry again. 

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.

My not very well informed assumptions might start by splitting
vulnerabilities into some classes applicable to this topic. E.g.

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.
[Maybe that's already understood, but it bears repeating, just in case.]
Such an application/platform on VMS on x86 will in principle have
the same potential vulnerabilities on VMS on Alpha (or on VMS on VAX,
or even on VMS on SPARC or PowerPC if such were to exist). And the same
as on pretty much any other plausible hardware architecture where the
same source code is in use. Broken source code is broken everywhere
(give or take).

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.
Cross-module parameter checking ought to be easy but doesn't seem
to be done as often or as thoroughly as it should. I had great fun
doing it decades ago, and having had similar fun with 'modern' object
formats in recent years, it ought to be just as possible nowadays.

'Unauthorised access to resources' and 'unauthorized elevation of
privileges' vulnerabilities will likely be different from OS to OS
(even on the same hardware).
E.g. what's exploitable on x86 on Windows isn't necessarily
exploitable on Linux/x86, and isn't necessarily going to be
exploitable on VMS on x86. Same goes for Alpha, not that it
matters now.

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.

One of the allegedly most widespread defacement exploits on
Linux occurred only on what in principle would sound like an
obscure combination of certain x86 Linux kernel versions in
64bit mode and certain Apache versions in 32bit mode and maybe
some other stuff. But it turns out it was a popular web server
configuration and once the script kiddies found it, it led to
huge numbers of website defacements, which were duly quoted
by MS as "proof" that Linux was less secure than Windows.

That particular vulnerability, which was an unauthorised
elevation of privilege, also involved a re-occurrence of a bug
which had been previously fixed several years earlier.
Ref: [1]

Obviously there's more kinds of fun to be had here (system crashers,
resource exhausters and so on). But that's more than enough for now.

Have a look, see what you think. Don't believe *everything* you read.

Don't necessarily even believe all of this. Some of this is from
memory, and my memory is not error correcting. 

Have a lot of fun.

[1]
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3301

2007 description: "The IA32 system call emulation functionality
in Linux kernel 2.4.x and 2.6.x before 2.6.22.7, when running
on the x86_64 architecture, does not zero extend the eax register
after the 32bit entry path to ptrace is used, which might allow
local users to gain privileges by triggering an out-of-bounds
access to the system call table using the %RAX register"