[Info-vax] Next release of OpenVMS x86

[Stephen Hoffman]

On 2020-07-20 17:47:55 +0000, Simon Clubley said:

> 2 vulnerabilities that came to public attention in recent years, not 
> the number of vulnerabilities found and fixed and which may not even 
> have had CVEs assigned.

There have been various security fixes over the years.

Most did not have CVEs.

I distinctly remember seeing a crash report that was posted, and that 
looked to be exploitable. That got fixed. No CVE for that.

CVE comparisons across platforms are patently absurd, and for multiple reasons.

And vendor-initiated CVE comparisons, when the vendor doesn't request 
and doesn't issue CVEs for their own security fixes, is a questionable 
look.

> BTW, didn't VMS V6 go through a major hardening exercise to fix a 
> number of security weaknesses ?

V6.0 was the last round of security enhancements; that was the Class B1 
and Class C2 integration work, with other security enhancements.

CDSA came along too, and has seemingly now overstayed, and digital 
certificate support needs to finish arriving and to start integrating.

App isolation, and app and system automation, and hosted server 
operations, and remote installs, will all bring along new requirements.

There's another round or three of security feature updates waiting for VSI.

> DECnet has also had successful attacks against it in times gone past.

Outside of under- or un-maintained legacy apps and the frozen-forever 
configurations, DECnet should not be in use.  Nor should telnet. Nor 
ftp.

That these and similarly-insecure protocols are still around and in the 
default install config is hilarious for "the world's most secure 
operating system".

> Network printers are still used on internal networks to print 
> documents. That doesn't stop them from also being used to attack the 
> rest of the internal network if they get compromised.

Yep. And the internal networks are far less internal than they once were.

> Are you sure ? It [possible IP vulnerabilities] might actually be the 
> other way around.

I've chased some nice security-related messes over recent years, and 
including a couple of OpenVMS servers were, for instance, getting 
buried by NTP reflection attacks and DDoS shenanigans.

With the NTP vulnerability, OpenVMS was busy, and the network link got 
full.  That got patched.

And the continued existence of unencrypted and password-exposing email 
POP/IMAP network connections isn't auspicious, if we're quibbling about 
cleartext protocols.

And as for portability, I was playing Whac-A-Mole with a user and a 
perl DoS tool that was running on OpenVMS, targeting others. Worked 
fine on OpenVMS, too.

And the available tooling options increase with x86-64, even if the 
exploits aren't usually all that portable.  Perl DoS tools and such 
aside.

> Don't forget that VMS doesn't even have ASLR let alone KASLR.

There's other work waiting here, too.

Try isolating an app against a latent vulnerability, even if it's an 
app that's believed non-malicious, What's involved here is hand-tweaked 
coding. And the isolation options are limited.

And necessary details such as app-specific usernames are still 
system-wide, and with the "fun" of coordinating UIC allocations, 
coordinating those wonderful personality logical names, and a host of 
other subtle details.

1980s-style management and manual coordination was nice, but it's 
really hard to automate that. And it's limited, with the sorts of 
shenanigans our servers are now encountering.

> SELinux has stuff like this built in:
> 
> https://en.wikipedia.org/wiki/Security-Enhanced_Linux

SEVMS is mostly latent. B&L-style security is approximately unusable 
for most folks and most apps, though. And does little to address 
app-level security, when it's the apps that are increasingly untrusted, 
or increasingly vulnerable.


-- 
Pure Personal Opinion | HoffmanLabs LLC