[Info-vax] VSI strategy for OpenVMS

[Stephen Hoffman]

On 2021-09-18 02:28:16 +0000, abrsvc said:

>> 
>> 
>> Everyone here knows about the DCL CVE and the fact it was directly  
>> exploitable on VAX and Alpha (and causes a crash on Itanium, so it was 
>> an open question about whether someone with sufficient skills and 
>> knowledge could do mischief on Itanium).
>> 
>> What you may have forgotten is that a few months before that, I had 
>> found another way to crash DCL by stuffing the recall buffer full of 
>> binary data. That earlier attempt also caused a crash, but it was not 
>> exploitable so nobody had to worry about it from a system compromise 
>> point of view.
>> Simon.
>> 
>> --
>> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
>> Walking destinations on a map are further away than they appear.
> 
> But,  both cases required being logged into an account correct?
> 
> This is different that an external attach not requiring access.
> 
> So answer this:  If OpenVMS is running on a VM and the VM is 
> compromised, is the problem with OpenVMS or with the VM?

Yes. When a VM is compromised, blame for the problem can be placed both 
within OpenVMS (for not detecting the issue) and the VM (for the 
compromise).

The VM is compromised, so QED.

OpenVMS hasn't gotten around to implementing secure boot, so cannot yet 
verify platform integrity.

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot 


(This as differentiated from the platform verifying that the operating 
system should be permitted to boot, and which VSI has occasionally 
discussed.)

OpenVMS started out in the we-can-trust-the-hardware era, and even 
without a hypervisor—"bare metal"—that assumption of trust is 
increasingly suspect.

> If OpenVMS is running on bare metal, would you expect external vulnerabilities?

Have you met iLO?

OpenVMS sites on HPE Integrity servers in the default configuration 
remain vulnerable to CVE-2013-4786. Which never got fixed. To avoid 
exposing your OpenVMS servers to this wonderful little remote-capable 
brute-force, VLAN or segmentation and/or firewall your OpenVMS servers, 
and preferably disable the feature MP:CM> sa -lanipmi d

That ain't the only one around, either. Down-revision and 
known-vulnerable cryptography still exists within iLO 2, as the iLO 
hardware itself was reportedly insufficiently capable for the 
implementation of newer cryptography.

Intel AMT has had its share of "fun", too. CVE-2020-0594 and 
CVE-2020-0595, among others.

And that's before any discussions of RCE flaws in OpenVMS itself. SMH 
had its share of flaws, for instance.

In general, "bare metal" is becoming a quaint concept. This given how 
many processors and how many disparate puddles of firmware lurk. These 
embedded within the server processor itself (AMT, etc), and variously 
embedded elsewhere within a modern server. Or elsewhere such as in your 
database or your testing and continuous integration.

As for fun with VMs, two recent rotate-your-credentials flaws in Azure.

https://www.theregister.com/2021/09/09/azure_container_flaw/

And anybody using Travis CI should rotate their credentials, too.

Rotating your credentials on OpenVMS is—once you start looking beyond 
SYSUAF and at the DECnet task passwords in the Phase IV database, and 
at Apache credentials, and at the strewn-about ssh and SSL/TLS private 
keys, and at iLO and its certificates, soon iDRAC and AMT—a project of 
some scope and scale, too. I'd be surprised if many of the folks around 
here could reasonably manage that credentials rotation, given what's 
involved and where these can now lurk. (This gets back to my earlier 
comments around password and credentials and certificate stores, and 
FDE, around updating the security manual and the programming concepts 
manual for this millennium, and a variety of other work.)

More of this "fun" will be arising, too. Various OpenVMS sites are 
looking to host their OpenVMS x86-64 servers. Yes, some sites 
absolutely won't host their OpenVMS servers, whether for legal or 
technical or other reasons. But many will. Maybe not production, but 
the build and test servers might be hosted.  q.v. Travis CI flaw.

OpenVMS didn't have a good way to reach into the iLO to look around for 
configuration problems or issues. It'll be interesting to see what sort 
of OpenVMS diagnostics might be available for x86-64 hardware 
configuration settings, as well as for hardware errors and other 
lower-level details. Vendor tie-ins are probably further down the list 
of projects at VSI right now, but maybe we'll eventually see some 
support for customizing OpenVMS for specific hardware akin to the 
probably-long-forgotten "SHIP kit" support for retrofitting drivers.

Ah, well. Pruning down your app and server and network and trust 
configuration is an obvious strategy, not that there are guidelines 
published for that, for system administrators or for app developers or 
for security reviews. And the hardware defaults can surprise the 
unwary, such as with iLO and IPMI. Pretty sure that assuming that the 
devs and the administrators will always do the right thing and will 
never make mistakes—assuming all _know_ what to do, which is suspect—is 
what got us into this mess, though. Mistakes happen. Plan for it. 
Доверяй, но проверяй.


-- 
Pure Personal Opinion | HoffmanLabs LLC