[Info-vax] DCL vulnerability write up on The Register

[Mark Berryman]

On 2/21/18 11:39 AM, Stephen Hoffman wrote:
> On 2018-02-18 21:45:03 +0000, Jan-Erik Soderholm said:
> 
>> Now, am I correct that, *if* you have a system where no non-priv'ed 
>> users has access to the DCL command line, then you do not have any 
>> problems with this? Becuse you cannot "use" this vulnerability if you 
>> do not have access to the DCL command line?
> 
> Not that I'd bet any particular OpenVMS system isn't leaking credentials 
> or access somewhere.   SCS. DECnet. FTP. telnet. leaked private keys.  
> Etc.  That's all before an attacker even has to get sneaky.
> 
> 

Oh, there are some that aren't leaking.  One of the first ways to ensure 
a secure VMS system is that you don't go anywhere near HP's IP stack.

As for your other examples:

SCS - on its own private LAN.  There is no way for anything other than 
the SCS hosts themselves to see the traffic.

DECnet - Mostly retired.  Public key SSH handles most of what DECnet was 
once used for.  However, local traffic on a private LAN.  Remote traffic 
encrypted.

FTP - anonymous FTP still useful for public data.  No usable credentials 
involved.  The data is obviously not sensitive as it is served to the 
public.  No actual accounts can be reached via FTP.

Telnet - not in use.  Equipment for which it was once in use has all 
been upgraded to versions that support secure access.

Leaked private keys - this would be a problem for any system.  Private 
keys must be kept secure but still available to the software that needs 
it.  Properly done, you would run into a whole lot of other problems 
before this became an issue.

Properly done, a VMS system can certainly be made secure (secure enough 
not to be broken into or leak data - there may be some classes of 
security it can't meet).  As would be the case with any system, the 
person setting it up simply needs to know what (s)he is doing.  The 
necessary tools and settings are available.

Mark Berryman