[Info-vax] Next release of OpenVMS x86

[johnwallace4 at yahoo.co.uk]

On Monday, 20 July 2020 20:00:56 UTC+1, Stephen Hoffman  wrote:
> 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

I'd have thought that Intel's various "Management Engine" 
vulnerabilities were about as portable and OS-independent 
as a vulnerability can be, at least for OSes that run on 
x86 servers and other kit with the IME or some variant 
thereof. Even Apple and MacOS, apparently. And soon 
VSIVMS. Is it a big issue outside the x86-dependent IT 
departments? Answers seem to vary.

Further reading via e.g.
https://en.wikipedia.org/wiki/Intel_Management_Engine#Security_vulnerabilities
If you're not a Wikifan, that's fine, there are plenty 
of other references too, for people interested enough to 
look.