From: gerard.calliet@pia-sofer.fr   
      
   Le 12/02/2026 à 02:10, Stephen Hoffman a écrit :   
   > On 2026-02-06 09:31:59 +0000, gcalliet said:   
   >   
   >> I am doing investigation about security for "latecomers" VMS users   
   >> (Vax, Alpha, Itanium on HP licence).   
   >   
   > What are configurations coasting with un- or semi-maintained servers.   
   >   
   > Yes, I am aware of industrial and SCADA environments, and regulatory   
   > environments, etc., and those typically don't get the sorts of security   
   > changes being discussed here. They get isolated.   
   >   
   > Or they get upgraded to VSI OpenVMS x86-64, or get incrementally ported   
   > over to Linux servers or such.   
   >   
   >> It seems being a not-so-little number of users. And for them, to adapt   
   >> to the fast cycles about security (SSH, SSL for example) is a challenge.   
   >   
   > It's much less of a challenge when the gear is not locked onto old   
   > hardware and old software versions.   
   >   
   > The overhead of adding (backporting) and maintaining security increases   
   > as time passes too, and the site usually attempts to isolate the older   
   > and more vulnerable servers.   
   >   
   > Or starts a modernization plan.   
   >   
   >> I know the Process Software offer for that, able to work with   
   >> everything on VMS.   
   >   
   > I'd not want to try implementing modern security particularly with a   
   > VAX, if performance is a consideration. VAX gear is ~35 years old, and   
   > slow. Usual approach is isolation, locked-down firewalls, and ongoing   
   > reviews.   
   >   
   > Alpha and Itanium are less bad here, performance wise.   
   >   
   >> Are there other offers, methods, Open Source initiatives...?   
   >   
   > Basically, no.   
   >   
   > OpenSSL does have a recent / current port to OpenVMS, there are the   
   > WASD-related pieces, but pragmatically most things available on OpenVMS   
   > are usually just very dated.  Porting the code gets harder the further   
   > back, too. There's other fun waiting too, probably including Xpdf and   
   > JBIG2, and the ever-popular CVE-2013-4786 for iLO:   
   >   
   > “HPSBHF02981 rev.4 - HPE Integrated Lights-Out 2, 3, 4, 5 (iLO 2, iLO 3,   
   > iLO 4, and iLO 5) and HPE Superdome Flex RMC - IPMI 2.0 RCMP+   
   > Authentication Remote Password Hash Vulnerability (RAKP)”   
   >   
   > TL;DR: ask the iLO nicely for a weakly-hashed IPMI password, then crack   
   > it offline.   
   >   
   > On at least some of these boxes, the iLO command that blocks this   
   > particular access:   
   >   
   > MP:CM> sa -lanipmi d   
   >   
   > https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c04197764   
   >   
   > If you have HPE OneView around, also check: CVE-2025-37164   
   >   
   > There are other vulnerabilities in some of the older versions of some   
   > HP/HPE apps for OpenVMS, too. Fixes never got ported. Some I've verified   
   > vulnerable from proof-of-concepts.   
   >   
   > Usual recommendation: Segment and restrict access to these OpenVMS boxes   
   > ("don't expose OpenVMS to the internet", etc), disable IPMI iLO access,   
   > set up a bastion host, etc. Get going on a modernization or migration plan.   
   >   
   > I've done some app retrofits here too, such as removing telnet   
   > connections that had failed audits, replacing those with TLS   
   > connections. But that was not on VAX.   
   >   
   Great thanks for these ideas.   
      
   And as usual, the issue is between the "must" and the "can".   
      
   Gérard Calliet   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)