[Info-vax] Anti-virus ?

[Stephen Hoffman]

On 2023-08-10 14:47:12 +0000, Bob Gezelter said:

> On Thursday, August 10, 2023 at 3:47:18 AM UTC-4, Niels S. Eliasen wrote:
>> Hello Believe it or not... but was asked by a customer yesterday: "What 
>> anti-virus software exist on OpenVMS ?" Anyone that has knowledge of 
>> such a product for OpenVMS ?...
> Niels,

That's going to be an interesting quest.

There's little add-on anti-malware for OpenVMS, with the DECdetect 
product (later known as "POLYCENTER System Integrity Checker") being 
long retired, and probably then sold off. DECinspect was deprecated 
long ago, and some of its security recommendations were... problematic. 
Some third-party might have an add-on scanner or related, but I'd tend 
to be skeptical about that.

The usual preferred source for these sorts of malware-scanning and 
security-scanning products would be VSI, and AFAIK they have none 
available. Check with VSI to see what they recommend, of course.

If you don't yet have VSI OpenVMS and VSI layered product app versions 
installed and in use, that's going to be an issue you'll want to 
address, too.

> First item, to the best of my knowledge there has never been an OpenVMS 
> virus, as the term is used in the Windows/Mac/linux world.

I wish that fiction would die, Bob. Yes, there have been classic 
viruses on OpenVMS. They are exceedingly rare, but have existed. U Mass 
Amherst had a DCL virus wandering around many years ago, IIRC. WANK was 
a well-known worm involving DECnet. Those sorts of malware 
threats—viruses, worms, etc—are also not the threats most OpenVMS sites 
will ever meet. OpenVMS usage is so tiny, nobody is going to bother to 
open distribute classic worms or classic self-replicating malware, 
though they might distribute it through a breach at various providers 
including VSI and some other entities. There are some really good ways 
to do that distribution, too.

That written, some of the more modern security practices such as 
monitoring outbound network activity from OpenVMS servers, and simply 
blocking and alarming various sorts of traffic, for instance, are very 
much applicable to local security.

Remote monitoring tools have been around, though those are mostly 
open-source add-on tools: 
https://groups.google.com/g/comp.os.vms/c/JwPp_iGtkLw/m/3E_RAchfBQAJ  
There is (or was?) a Zabbix port around, for instance. VSI IIRC had a 
syslog (or syslogng?) port, too.

> If you check the industry databases of known vulnerabilities, e.g., CVE 
> , it is rare for OpenVMS to be mentioned. There have been 
> vulnerabilities referencing OpenVMS, generally involving OpenSource 
> software ported to OpenVMS, e.g., the year 2028 issue for Unix style 
> 32-bit dates.

It is rare for OpenVMS to be mentioned because OpenVMS is only rarely 
used, and because the OpenVMS vendors didn't and generally don't log 
and don't track CVEs.

There have been repeated CVEs involving a couple of packages found on 
various OpenVMS configurations, but those CVEs were never listed for 
OpenVMS. I reproduced some of the posted exploits for one of the 
add-ons against OpenVMS (SMH, which is tied into SNMP), but didn't 
bother reporting as the vendor had retired the SMH app on OpenVMS. The 
Log4J mess (CVE-2021-44228, CVE-2021-45046) also hit some OpenVMS 
configurations. There are others.

2028 (specifically 31-Dec-2028) will break some security-relevant stuff 
for existing installations—this effects DEC, Compaq, HP, and HPE 
versions, and not VSI versions—but I'd suspect that was not your (Bob) 
intended reference. 2038 and not 2028 for the signed 32-bit time_t 
overflow, and 2038 AFAIK was not a CVE. 2038 was explicitly outside the 
OpenVMS Y2K checks too, so I'd tend to expect the possibility of some 
issues arising there.

> Common pathways used by malware to infect systems are also not as 
> prevalent on OpenVMS as on platforms where web browsers are commonly 
> used.

I've dealt with a half dozen or so OpenVMS breaches, and most were 
targeted though some configuration weakness or another, through 
data-protection errors, or by insiders.

> Holes in underlying processor firmware and virtualizations are a 
> hazard, but I not recall any Windows anti-virus product addressing that 
> class of exploits. All mitigations involving processor timings are 
> typically remediated by "not doing that". I admit that I do not believe 
> that "not doing that" is not a good solution in any context.
> Simon's question concerning "data at rest" is a valid concern, but can 
> be addressed by using appropriately configured storage devices.

OpenVMS support for protecting data at rest past the built-in AES 
product is weak at best, and support for protecting data in motion is 
also weak, and certificate support is just hilariously sad, and 
vendor-provided password and certificate storage and related 
protections are entirely missing.

Basically, writing secure apps on OpenVMS is a royal pain in the arse, 
this having worked on OpenVMS and on other platforms. I'd expect most 
installations—OpenVMS or otherwise—don't bother with that work until 
and unless some audit or some external linkage requires fixes or 
waivers, too.

Whether you want to open up a configuration and app security review, 
past answering the mostly-non-existent add-on anti-malware question?

PS: OpenVMS is well-positioned for running an OpenVMS install read-only 
with the WRITABLESYS write-locked system disk support, but I'd not 
expect to see more general use of that—past CD and DVD media—appear as 
a security enhancement anytime soon.


-- 
Pure Personal Opinion | HoffmanLabs LLC