[Info-vax] VSI strategy for OpenVMS

[chris]

On 09/18/21 17:29, Stephen Hoffman wrote:
> 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. Доверяй, но проверяй.
>
>

Add to which, have a global security strategy that doesn't depend on
the OS being secure. That means firewalling, secure subnets, access
controls and much more. Have to assume that any system can be broken,
given enough time and resources...